[beta.30][P2] Reconcile exact job-definition mutation replay before mutable ETag validation #333

Problem

On released 0.1.1-beta.29 at source 4b148ebe824b3de445a12d30e95b8f5c30d53655, an exact replay of an already successful owned job-definition update returns HTTP 409 job_etag_mismatch. An independent parameter-add replay fails in the same way.

This is DEF-B29-01 from the owner's beta.29 checkpoint. The public reproduction below uses synthetic owned fixtures. Private identities and raw campaign evidence remain outside GitHub.

Tracking: release epic #282; owner functional acceptance #305 under #294. Related completed repair #316 concerns compound job-start admission, a different path, and stays closed.

Minimal reproduction

1. Create a disposable inert job owned by the caller.
2. Preview an update with expectedVersion: 1.
3. Confirm that unchanged request using the issued plan token and idempotency key. It succeeds and returns version 2.
4. Immediately repeat exactly the same confirmation while its plan remains valid.
5. Observe HTTP 409 job_etag_mismatch, although readback still shows the original successful update at version 2 and no second write.
6. Independently preview and confirm adding an ordinary nonsecret parameter, then repeat its exact successful confirmation. The replay returns the same ETag conflict; the parameter exists once.

Positive controls in the same checkpoint: create replay returns the original job, job-start replay returns the same run, a fresh stale write is rejected, changed confirmation data does not persist, and two competing same-version updates produce one winner.

Expected behavior and impact

An exact replay bound to the same authorized principal, tenant, operation, target and payload should reconcile the recorded successful result without applying the mutation again. A client recovering an uncertain successful response currently receives a conflict instead of that result.

The owner observed no duplicate execution, data corruption or authorization bypass. The reproduced problem is unsuccessful reconciliation after a successful mutation.

Source diagnosis

McpOperatorJobEndpoints.ConfirmMutationAsync at the tested source calls ValidateMutationAsync, including the mutable current-version check, before confirmations.ConfirmAsync can identify the consumed exact replay.

Focused repair

Reconcile an already consumed, exactly bound confirmation before validation that only governs a new dispatch. Preserve current identity, tenant, policy and ownership enforcement plus exact confirmation binding. New stale writes, changed requests, expired plans and cross-principal or cross-target reuse must continue to reject without side effects.

Review every equivalent definition mutation, including parameter and step changes, and deletion. Successful delete replay must be reconciled using the retained authorized binding and result even when the live definition no longer exists; absence alone must never become authority to disclose another principal's outcome.

Extend the existing endpoint/store regression layers. Do not add a parallel campaign framework or a release-specific CI pipeline.

Acceptance criteria

• Exact successful update and parameter-add confirmations replay the recorded success with no second version increment, parameter insertion, audit mutation or execution.
• Equivalent definition operations follow the same contract; exercise a representative parameter/step mutation and successful deletion replay.
• A consumed successful replay remains reconcilable after a later definition change or deletion, under the original valid confirmation contract and current authorization.
• A new stale request still returns the expected concurrency conflict. Two new competing same-version writes still produce exactly one winner.
• Changed payload, actor, tenant, operation, target or confirmation credentials cannot retrieve or apply the original result; expired/revoked/unauthorized access remains denied.
• Existing create replay, same-run job-start replay, start revision binding and persisted readback controls remain intact.
• Focused tests cover the response-loss/retry scenario and verify durable mutation count; required PR/main validation and the ordinary hosted release pipeline pass.
• Include the fix in the next available beta.30 release artifacts, then retain fresh owner retest in [beta.30][P1] Finish admitted MCP functional, runtime and policy-race acceptance #305/[QA-CAMPAIGN] Complete 37 retained HTTP MCP contexts and owner release gates #294. Publication does not itself close owner production acceptance.