bug(sub-agents): SendMessage from orchestrator carrying user-confirmed authorization is treated as untrusted, blocking convergence

## Summary
When the orchestrator (or any parent agent) relays a user-confirmed authorization via `SendMessage` to a sub-agent, the sub-agent's security model can reject the message as "carrying no user authority". This causes a confirmation loop: the sub-agent asks for direct user confirmation; the user confirms via the orchestrator's `AskUserQuestion`; the orchestrator relays via `SendMessage`; the sub-agent again rejects it as having no direct user authority.

## Repro / observed pattern
1. Orchestrator dispatches a sub-agent (test-writer) with task that turns out to need a small out-of-scope edit (raising a lint config knob).
2. Sub-agent reaches the out-of-scope edit, correctly stops, asks the orchestrator: "is this authorized?"
3. Orchestrator asks the user via `AskUserQuestion`; user confirms.
4. Orchestrator relays confirmation via `SendMessage(to: sub-agent, message: "user confirmed: do X")`.
5. Sub-agent **rejects the relayed authorization** as having no user authority. Asks again.
6. Orchestrator has to abandon the SendMessage path and spawn a FRESH sub-agent with the authorization baked into the initial dispatch prompt — which the fresh sub-agent DOES trust.

## Why this matters
- This security stance is principled (parent agents could fabricate fake user confirmation), but the user-experience side is broken: the user IS confirming, the orchestrator IS relaying accurately, and the work-around (fresh dispatch with bigger prompt) just hides the trust gap behind a different attack surface.
- In long-running multi-agent workflows, this can add 1-2 extra dispatch rounds per scope-confirmation cycle.

## Suggested mitigations (pick one or more)
1. **Cryptographically signed authorization tokens** — when the orchestrator asks the user a question, the harness mints a one-time signed token. The orchestrator relays the token along with the message; the sub-agent verifies the signature against the harness.
2. **Direct user channel for sub-agents** — when a sub-agent needs confirmation, escalate to the user directly (rather than via the orchestrator), and require the user's response to be delivered to that specific sub-agent.
3. **Explicit "trusted relay" annotation in SendMessage** — orchestrator can flag specific messages as "user-confirmed via AskUserQuestion at "; sub-agents are configured to trust those.
4. **Accept-then-audit pattern** — sub-agent proceeds when message looks user-confirmed and the orchestrator records the relay; harness audits later.

## Related
- #258 (separate but related: synthetic harness messages misrepresenting user intent)
- #223 (when to use SendMessage vs fresh Agent dispatch — this issue exposes a trust-model reason why operators are forced toward fresh dispatch)