Define a retro receipt path after project-log sealing

[tkstang]

Summary

The project completion and retrospective contracts currently conflict when a retrospective is explicitly requested after completion:

• completion requires the seal to remain the final project-log.md entry;
• retrospective generation expects to append a structural receipt when that log exists.

A completed project therefore has no compliant place for the later retro receipt.

Proposed behavior

Define a post-completion receipt path that preserves both invariants. Possible mechanisms include a dedicated addendum ledger or a receipt stored on the durable project ref outside the sealed project log.

Acceptance criteria

• A retro requested after lifecycle completion can record a durable structural receipt.
• The completion seal remains the final entry in project-log.md.
• The receipt is discoverable from the completed project's durable artifacts.
• Shared, synced, and other durable scopes have an explicit persistence rule.
• Retry and idempotency behavior are defined and tested.
• The retro workflow no longer gives mutually incompatible instructions after completion.

Related

• Retro should preserve/addendum, not overwrite a finished project-retro.md #209 covers preserving an existing rendered retrospective when later evidence is added. That is adjacent but distinct from locating a receipt after the project log itself has been sealed.

[tkstang]

Triaged in PR #253 (record). Folded into BL-260902-append-only-lifecycle-history together with #209 and #210; the receipt location needs a design decision before planning.