Add governed human-action routing

[alexhraber]

Context

PR #2 deliberately exposes no mutating controls. Future controls must route through Pincher and/or Decapod and wait for authoritative acknowledgement; a keypress must never locally change governance state.

Scope

Add explicit, receipt-backed routing for supported human decisions:

• approval/interlock decisions;
• cancel, pause, and resume requests where Pincher supports them;
• handoff acceptance or rejection;
• confirmation semantics for consequential actions;
• correlation receipts, timeout, retry, and failure behavior;
• authoritative acknowledgement before projection state changes.

Controls should be modeled as requests and receipts, not local state transitions. The UI should remain clear about requested, acknowledged, rejected, timed out, and unavailable states.

Non-goals

No local approval store, optimistic pending→approved or ready→promoted transition, direct provider/tool execution, or bypass of Decapod interlocks.

Acceptance criteria

• Every action carries intent/run/session/work-unit correlation and a request ID.
• The UI cannot display an authoritative approval/proof/promotion change before an authoritative receipt.
• Confirmation and cancellation behavior is explicit and keyboard discoverable.
• Timeouts, denied actions, disconnects, duplicate receipts, and late receipts are safe and inspectable.
• Tests prove each prohibited optimistic transition remains impossible.
• The calm default view shows only meaningful action state; raw receipts remain progressive detail.

Dependencies

PR #2’s read-only app state and projection contract; real Pincher adapter; authoritative Decapod enrichment; published Pincher action/receipt contract.

Validation expectations

Run request/receipt integration tests, duplicate/timeout tests, authority failure tests, cargo fmt/test/Clippy, and Decapod validation/proof checks.

Related: #2