docs(release): trace sealed sales-readiness source identity

Author: seonghobae

docs/changelog.d/1717-codeql-pr-lifecycle-recovery.md

@@ -9,6 +9,7 @@
 - Seal every step-declared acceptance artifact with a root-relative SHA-256 in `acceptance_summary.json` and replay that digest before buyer-packet admission, so post-acceptance in-root mutation cannot be relabeled as accepted evidence.
 - Keep benchmark and release-index HTML evidence inside each manifest's resolved evidence root and verify the recorded HTML SHA-256 before adding it to the buyer packet.
 - Bind the buyer packet's `source_commit` to the release-acceptance summary's sealed `source_commit`; acceptance evidence from another revision now fails closed instead of being relabeled as current evidence.
+- Require canonical sales-readiness output to carry forward the acceptance summary's validated lowercase full `source_commit`; source-bound buyer-packet admission rejects a missing sales-readiness identity, and acquisition stage verification requires the persisted identity to equal the sealed source revision.
 - Reject sales-readiness, benchmark, and release-index evidence whose explicit `source_commit`, when present, disagrees with the buyer packet's sealed source identity instead of silently embedding contradictory provenance.
 - Require release acceptance, sales readiness, and any supplied benchmark or release-index evidence to report `status: ok` before their evidence can be promoted into a buyer packet whose own status is `ok`.
 
@@ -24,7 +25,9 @@ Cross-revision acceptance RED `b2c3a792aadc7cce08b0e57db364fbdfd2ff8f` proves th
 
 Upstream-status RED `087588114ef4bd0aefdf56465cc937147d51ac28` proves that failed release-acceptance or sales-readiness manifests could previously be embedded while the buyer packet itself still emitted `status: ok`. Causal GREEN `6ae7fdfa412d5619364cc26298e2de22bf6d4160` reads both bounded manifests before collection and fails closed unless each reports `status: ok`.
 
-Cross-revision sales-readiness RED `961dfadb05cc95541023f61c5ec06a7e319d2dcf` proves that a sales-readiness manifest carrying an explicit source identity could disagree with the packet's exact repository revision and still be admitted. Causal GREEN `1bba24be881b6758364b3b44446fc96867465d58` rejects that contradictory identity before collecting packet files. This guard is intentionally non-vacuous but backward-compatible with the current sales-readiness schema, which does not yet emit `source_commit`; making that upstream identity mandatory remains a separate schema-owner follow-up rather than being falsely claimed by this repair.
+Cross-revision sales-readiness RED `961dfadb05cc95541023f61c5ec06a7e319d2dcf` proves that a sales-readiness manifest carrying an explicit source identity could disagree with the packet's exact repository revision and still be admitted. Causal GREEN `1bba24be881b6758364b3b44446fc96867465d58` rejects that contradictory identity before collecting packet files. The original guard deliberately tolerated omission while the upstream schema lacked `source_commit`; the schema migration below removes that omission from the canonical source-bound acquisition path.
+
+Sales-readiness source-identity RED `62ea308fcd04fce345fb11ab915223e001d7c9fe` requires the sales-readiness manifest to inherit the sealed acceptance revision, requires source-bound buyer-packet admission to reject a missing sales-readiness identity, and requires acquisition stage verification to treat sales readiness like every other source-bound generated stage. Forward repairs `2566f1a570d544b54882775272a24d0490b8fbb1`, `9501a3ff6e7894fec0f58ee71f4633554e508008`, and `e81dcf2272517b5fb33e617f5ff488fc85d525d0` carry and validate the identity at the producer, buyer boundary, and acquisition verifier respectively. Direct legacy/non-Git rechecks may still consume an acceptance summary without source identity and emit `source_commit: null`; that output is not admissible as source-bound buyer evidence because canonical packet construction supplies an expected source revision and fails closed on the omission.
 
 Optional-evidence status RED `279c8a3c3ddbc3b112c0ddd06fe39979062c5b5d` proves that a supplied failed benchmark report or failed release-evidence index could still be embedded while the buyer packet emitted `status: ok`. Causal GREEN `f685c8628aa47e220368b7928bec779c418f27e2` rejects either failed optional manifest before its JSON or linked HTML is admitted to the packet.