Reconcile validation authority with immutable execution profiles (blocked foundation)

[justsml]

Preserves the reviewed #158 integration without admitting it to main. The immutable profile and newer background/resume hardening are retained; authority provenance tests and typecheck pass.

Blocked: production tool/workflow call sites do not provide resolveExecutionAuthority, and the public tool does not pass the self-mode decision. Wire server-owned task scope, target authorization, policy decision and exact durable approval, then verify through the public tool seam. The four-mode paid matrix remains closed. This draft also contains the prerequisite #196/#152/#157 foundation commits; it must be refreshed after those merge. No paid model calls or human-review approvals were performed.

[justsml]

Retargeted from integration/main-20260912 to main. That old base is fully merged (0 commits ahead of main), which was inflating this PR's diff to 46 files / +4824; the true remaining delta is 19 files / +1148 −29. It now shows conflicts against main and needs a rebase.

Do not merge as-is. Verified against current main, the held reason in docs/branch-integration-2026-09-12.md still stands and is worse than the one-line summary suggests:

1. The execution-authority resolver is never constructed in production — resolveExecutionAuthority exists only as a test stub (tests/integration/validation-authority-provenance.test.ts:120). All four executor sites in src/mastra/tools/validation-plan.ts (:393, :415, :437, :459) and src/mastra/workflows/validation-plan-workflow.ts:60 omit it, so resolvePayloadAuthorities returns an empty map and every payload denies server-authority-not-resolved.
2. Self mode is unreachable — modelDecision is never supplied by the tool, so self mode denies every payload and can never confirm.
3. Latent breaking change — requireModelValidationAuthority throws on plans with no pinned authority, so plans from src/mastra/tools/finding-helpers.ts:156, from the workflow, and any already persisted, would hard-fail record_result and confirm. This must land in the same change.
4. Riskiest line: executor.ts:414-418 returns unconditional true for auto/self, relying entirely on the per-payload resolver to fail closed. A mis-wired or permissive resolver silently removes the destructive-payload guard. Needs a direct test before anything here merges.

Good news on the two fields that looked like they had no producer: policyDecisionId can anchor to ContainmentPolicySnapshot.id from resolveContainmentPolicy (merged via #152), and taskScopeVerified derives from the existing findTargetAuthorizationCoverage. Neither needs inventing.

Tracked by #100.

[justsml]

Superseded by #216, which completes this work on a fresh rebase onto current main.

#216 builds the production resolver that was missing here (it existed only as a test stub), wires all four executing tool actions plus validation-plan-workflow, makes self mode reachable, adds the operator mode selection, and handles the unpinned-plan migration that would otherwise have hard-failed record_result/confirm on existing plans.

It also fixes a real bug the adversarial test exposed: a throwing resolver escaped executePlan and crashed the tool instead of denying — which, given that executionApprovalGranted returns unconditional true for auto/self, was the difference between failing closed and having no destructive-payload guard at all.

Closing this draft. Branch integration/validation-foundation-20260912 is preserved.