fix(macapp): bind composer and ToolWalk lifecycle to submitted run identity

[dennisonbertram]

Problem

Independent review of #1127 found two P1 action-ownership gaps after #1125:

1. Composer captures only a run ID but branches on live run.canSteer; stale A steer may fall through to project.submit().
2. ToolWalk polls currentRunID after submit and can capture B if external B replaces A first; timeout/automatic approval/input can then act on B.

Acceptance criteria

• Composer captures rendered action mode and owner. A stale steer is a no-op and never submits a new run.
• ToolWalk binds its full lifecycle (timeout, automatic approval/input, terminal wait) to the exact submitted/local run ID, never dynamic current run.
• Deterministic A->B-before-first-poll tests prove no B cancel/approve/answer/submit request; legitimate A path remains functional.
• Preserve fix(macapp): acknowledge run-control failures and preserve pending user input #994 single-flight/delayed ACK, fix(macapp): clear stale interactive affordances when external run ownership changes #1122/fix(macapp): fence stale stop and steer actions to rendered run identity #1125 explicit guards, external force isolation, and visual scheduled state.
• Sol medium diagnosis, cheap re-review, strict/full Swift/repo/hosted gates.

Scope

Native Composer/ToolWalk run-identity ownership only, stacked after #1127; blocks stack promotion.