feat(delegation): add reviewed operator path from legacy Goal to managed-worker acceptance

[huangruiteng]

Problem

The shipped managed-delegation surface can configure and inspect a codex-cli binding, but an existing legacy-authority Goal stops at state=authority_unavailable with:

Goal acceptance requires an existing canonical authority; activation never promotes a provider

This fail-closed behavior is correct. The product gap is that the operator has no supported, typed next step from that result to a separately reviewed promotion/qualification operation. delegation inspect cannot launch a worker (also correct), while the documented shadow/admin commands do not constitute provider promotion. As a result, an existing Goal can have a valid managed-worker binding, pinned Todo validator and isolated workspace yet no actionable path to the first accepted result.

This is visible in the capable-manager journey tracked by #4339: a capable manager can choose a managed Codex worker, but the request cannot become an accepted/adoptable result for a Goal still on legacy local authority.

Smallest useful slice

Add one provider-neutral, operator-owned path that:

1. reads the current Goal authority mode and exact preconditions;
2. produces a dry-run/preview with the selected provider, qualified revision, legacy-writer fence and rollback identity;
3. requires an explicit execute step for promotion and never promotes from delegation start/inspect, capability activation, Dashboard rendering or Lark;
4. returns typed actionable reasons for missing qualification, stale source revision, unverified fence, unsupported provider and already-promoted state;
5. lets the original managed-delegation preflight succeed after verified promotion without changing its binding or Todo identity.

Reuse the existing TypeScript promoteLocalCoordinationAuthority transaction and its exact revision/fence checks. Do not add a second authority writer or a Python semantic owner.

Entry points and acceptance

• CLI: operator preview/apply/readback with idempotent operation identity and exact source/provider revisions.
• Frontend: existing Goal control-plane/capability surface shows the same preconditions, explicit confirmation boundary and readback; no second source of truth.
• Lark: read-only projection of unavailable/ready/promoted state and next action; no promotion grant from chat.
• Managed delegation: inspect/start/read remains fail-closed before promotion and consumes the same canonical authority after promotion.

Validation should cover a disposable legacy Goal through shadow qualification → preview → execute → restart → managed-worker acceptance, plus stale-revision, crash/replay, malformed/missing fence, already-promoted idempotency and rollback guidance. Include a packaged frontend check and verify that no worker/model starts before authority is ready.

Non-goals

• implicit provider promotion;
• weakening canonical acceptance or falling back to Markdown;
• choosing SQLite/NoKV/PostgreSQL as a new default;
• coupling Lark delivery authority to control-plane promotion;
• claiming full M2/M4 completion.

Related: #4339 and the shared-goal authority RFC. This issue is the product/operator bridge between their existing contracts, not a replacement ledger.