Release controller refresh cannot advance a second generation projection

Summary

The release/v0.1.0 authenticated controller-refresh port cannot advance beyond its first committed controller generation. A second compatible refresh durably appends and authenticates its journal event, but projection reconciliation rejects the exact first-generation metadata/state projection as conflicting with the new head. Lifecycle recovery fails after the second journal entry commits and before controller launch.

Minimal generic reproduction

1. Initialize a temporary generic external Solidity project and launch a small topology with a fake terminal workflow runner.
2. Prepare, materialize, and commit one authenticated controller refresh.
3. Make a synthetic controller-only byte change that preserves the same semantic fingerprint.
4. Prepare and materialize the second controller generation, whose authenticated predecessor is the first generation.
5. Commit the second generation.

Focused result on the release port:

not ok - controller refresh advances a second committed generation from its prior projection
controller generation projection conflicts with its authenticated journal head
0 passed, 1 failed

At failure, the append-only journal contains two committed entries with valid linear ancestry, while both metadata and state still project the exact immediate predecessor.

Expected behavior

For a non-initial committed head, reconciliation should accept only complete projections of either the authenticated immediate predecessor or the current head, including the matching journal and snapshot paths. It should then atomically advance metadata and state to the current head. Initial all-absent projections and the expected crash boundary between metadata and state should remain recoverable; unrelated, partial, or non-linear projections must still fail closed.

Existing implementation evidence

Equivalent release-port semantics and a broader crash/tamper regression already exist in UltraFuzz-owned commit d0d14a7358d311f072985199c540fd2618423aaf, but those semantics are absent from the current release branch.

Suggested regression checks

• A second compatible controller generation advances from the exact first-generation projection.
• A crash after metadata projection but before state projection reconciles idempotently.
• Unrelated generation, journal, or snapshot projections remain rejected.
• Both committed generations and their events remain readable after reconciliation.

Related to #721, but this is a distinct multi-generation projection failure in the release port.

Start with the release/v0.1.0 authenticated controller-refresh port and compare its reconciliation path with UltraFuzz commit d0d14a7358d311f072985199c540fd2618423aaf. Run the minimal generic external Solidity reproduction and the suggested regression checks for a second generation, crash recovery, and rejected unrelated projections. Done means both committed generations remain readable while valid projections reconcile and invalid ones fail closed.