spec: define the confirmation contract behind action.ai.requiresConfirmation — an unconfirmed run_action on a gated action is refused, and the refusal carries the way to confirm #16293

Split from #15942 by the director seat under decision batch #54 (maintainer 「同意」 on recommendation A, 2026-09-06). This is the spec half; #15942 stays the runtime half (MCP run_action enforcement) and is pm:blocked on this card.

The ruling this card implements

action.ai.requiresConfirmation is a safety flag that today only fills one field of the MCP list_actions summary; the spec's own guidance (packages/spec/src/ai/tool.zod.ts:59-68) and the ADR-0049 ledger entry 17.tool-requires-confirmation-retired.ts tell authors it "actually stops execution". The maintainer ruled A — enforce it, in the minimal shape:

• a run_action (MCP, and any other AI-facing action door) against an action declaring ai.requiresConfirmation: true must carry an explicit confirmation — a confirm: true request member or an equivalent confirmation token — or it is refused loudly with a registered ADR-0112 code and a response that tells the caller how to confirm and retry;
• no approval queue, no parking, no server-side HITL workflow in this card — that is a separate, larger decision if ever wanted;
• list_actions keeps reporting the flag truthfully (unchanged).

What this card owns (spec surface)

1. The request-side contract: where the confirmation rides on the AI action request (packages/spec/src/contracts/ai-service.ts around :190, and the MCP request shape), spelled as a closed member — not a free-form header.
2. The refusal: one new ERROR_CODE_LEDGER member (e.g. ACTION_CONFIRMATION_REQUIRED) under the owning package, status 4xx (the request is valid but incomplete — the caller can fix it), with the response carrying the action name and the exact member to set.
3. Rewrite the two misleading passages so they describe the enforced behaviour rather than a queue: tool.zod.ts:59-68 and the ADR-0049 ledger entry's replacement prose. The runtime's own "HITL hint" comment becomes false once MCP run_action never enforces ai.requiresConfirmation — it is surfaced in list_actions only, while @objectstack/spec guidance tells authors it stops execution #15942 lands and is that card's to update.
4. Changeset minor on @objectstack/spec (additive: one request member, one code); Clause-②: yes on both carriers.

Not in this card

• The runtime enforcement itself (packages/runtime/src/action-execution.ts, invokeBusinessAction pre-dispatch checks) — MCP run_action never enforces ai.requiresConfirmation — it is surfaced in list_actions only, while @objectstack/spec guidance tells authors it stops execution #15942.
• Any per-principal opt-in mode (option C was not chosen).

Re-check before claiming

grep -n "requiresConfirmation" packages/runtime/src/action-execution.ts   # expect exactly :980 (read) and :1014 (list_actions projection) on main
grep -n "requiresConfirmation" packages/spec/src/ai/tool.zod.ts packages/spec/src/migrations/entries/semantic/17.tool-requires-confirmation-retired.ts