Validate activation finalization and explicit no-create reconciliation #2203

Problem

An authorized activation can currently queue issue creation and publish an invalid acceptance containing unresolved temporary references, missing binding metadata, or an artifact-kind mismatch. A successful run is not proof that downstream consumers can safely use the resulting record. Repeating creation risks duplicate issues.

Generic example: a task is created with temporary_id: aw_wi1, but its binding still contains "issue":"aw_wi1" and a dependency field retains a bare temporary token. These examples are synthetic.

Scoped repair

• Use one guarded deterministic activation writer with frozen plan/registry inputs and actual synchronous create results; validate bindings before acceptance becomes consumable.
• Persist a no-create reservation before issue creation. Partial or ambiguous outcomes must not permit recreation.
• Support separately authorized current-state-only reconciliation using exact source/request IDs and hashes, complete explicit existing-issue mappings, and current API validation. Preserve the original record and make no historical-attestation claim.
• Permit only narrowly validated dependency-reference corrections, with before/after hashes, fresh conflict checks and documented non-atomic concurrency limits.
• Preserve safe phase continuation and combined implementation-phase acceptance through the same guarded path.
• Ship deterministic checker/SDK selection and all required packaged runtime surfaces together.

Acceptance criteria

• Authorized malformed legacy activation is rejected before any issue create; read-permission rejection remains independent.
• Executable coverage includes malformed/duplicate/cross-repository references, partial writes, interruption recovery, retries/no duplicates, complete phase bridges, combined phase activation and fail-closed downstream selection.
• A pending reservation alone grants no recovery authority; complete current-state mappings and eligible request authorization are required.
• Existing valid acceptance behavior remains supported; malformed or ambiguous records remain rejected without an explicit validated supplement.
• Verify pinned compiled custom-handler wiring, package closure, normal build/tests and independent review. Merge only after exact-head checks/rules and review qualification; no bypass.

Out of scope

No credential or policy changes, foreign-repository writes, implementation dispatch changes, live consumer application, or reopening merged predecessor PRs.