[P0][security] Flow runAs never switches execution identity

[os-zhuang]

Part of the metadata liveness audit umbrella #1878 (P0 security cluster).

Problem

Flow runAs never switches execution identity. The service-automation engine ignores it, so a flow declaring runAs: system does not elevate, and one declaring a restricted identity does not de-elevate. Steps execute as whatever the triggering context already was — a privilege-boundary surprise in both directions.

Decision required (enforce or remove)

• Enforce: have the engine establish the declared identity/permission context for the duration of the run (and restore it afterward), respecting runAs: system vs a named principal.
• Remove: drop runAs from FlowSchema if identity switching is not going to be implemented, and document that flows always run as the trigger's identity.

Evidence

• docs/audits/2026-06-flowschema-property-liveness.md
• service-automation engine (runAs unconsumed)

[os-zhuang]

Experimental marking landed in #1902 (ADR-0049): this property is now flagged [EXPERIMENTAL — not enforced] in the spec so authors aren't misled. This issue stays open to track the actual enforcement (or removal with the feature) at M2 — the marking only neutralised the false promise, it did not implement the behaviour.

[os-zhuang]

Resolved by #2302 (squash-merged to `main` as 6c4fbd9).

ENFORCE. The platform expresses elevated identity via the ObjectQL `options.context` (`{ isSystem: true }` bypasses RLS; `{ userId, roles, … }` scopes it), so `runAs` is enforced rather than removed.

Root cause: the CRUD nodes passed no identity at all to ObjectQL, so the security middleware was skipped entirely — every flow ran effectively elevated regardless of `runAs`.

The fix:

• The engine establishes the run's data-layer identity from `flow.runAs` at setup (on a context copy, so the caller's context is restored afterward) and persists it on suspend so `resume()` re-establishes it.
• Every CRUD node passes `options.context` via `resolveRunDataContext`: `system` → `{ isSystem: true }` (elevated, RLS-bypassing); `user` (default) → the triggering user `{ userId, roles, permissions, tenantId }` (RLS-respecting; can never exceed the trigger's grants).
• The REST trigger route + record-change trigger now forward the caller's `roles`/`tenantId`, so `runAs:'user'` matches a direct request by that user.
• Removed the `[EXPERIMENTAL — not enforced]` marker; `docs/audits/2026-06-flowschema-property-liveness.md` marks `runAs` live; the spec liveness ledger classifies `flow/runAs` as a proof-backed high-risk class (ADR-0054).

Proven both directions, RED→GREEN: dogfood gate `flow-runas.dogfood.test.ts` (a restricted member triggering system vs user flows on an owner-scoped record) + service-automation unit/regression tests `crud-runas.test.ts`.

Behavior change: flows that relied on the implicit elevation now run as the triggering user — declare `runAs:'system'` on flows that must exceed the trigger's access. Schedule-triggered runs (no trigger user) under `user` stay unscoped; tracked as a follow-up.

Part of the metadata-liveness audit umbrella #1878 (ADR-0049).