Regen: the third generation of #8691's clone-drop, three sites the second could not see

[gunbai-bot]

MAIN IS RED ON required-regen AND HAS BEEN SINCE 1caf8d5. This adopts the
emitted mirror that closes it.

WHAT IS WRONG. claim_executor --required-regen reports
first_generation_equal=false with generated surface drift: v1_compiler_emit_rust.rs. Measured on main directly, not inferred from a
branch: run 32603243451 at 1caf8d5 FAILS, and its parent f2d1ae7 (run
32603180703) SUCCEEDS, as do 0387bc6 and aaf7869 before it. 1caf8d5 is
#8691, the sharing.iter_owned receiver clone-drop. Every commit merged after
it inherits the red.

WHY A CORRECT COMMIT LEFT A RED BEHIND, and this is the whole point rather than
a defect in #8691. An emitter change is the one class where generation N cannot
observe its own effect: the committed stage0 binary emits the new mirror with
the OLD emitter. #8691 did regenerate — its own mirror first, then the 56-file
cascade once claim_executor was rebuilt from that mirror; its commit message
narrates both. So it is INTERNALLY SELF-CONSISTENT. That is a different
property from being A FIXED POINT OF THE EMITTER IT DESCRIBES, and only the
first was established. first_generation_equal is a fixed-point predicate over
the emitter, not a validity predicate over the Rust: false says generation N+1
differs, not that anything emitted is wrong.

WHAT THE THIRD GENERATION SEES. Three sites, all in the emitter's own mirror:

emit_file_path_line for p in parts.clone().iter().cloned() -> parts.iter().cloned() (x2)
emit_file_return for ch in fields.clone().iter().cloned() -> fields.iter().cloned()

Exactly the transformation #8691 introduced, at three receivers the generation
before it could not reach.

HOW THIS WAS PRODUCED, so the next person can repeat it rather than guess. One
remote dispatch, looping: build claim_executor from the committed mirrors ->
run --required-regen -> adopt every candidate file that differs -> rebuild
from the newly-adopted mirrors and re-run, stopping when regen exits clean.
That loop is what converges; a single adoption is not guaranteed to, because
each generation can only see the previous one's effect. It converged at round 2
(round 1 adopted this file, round 2 came back first_generation_equal=true).

RE-VERIFIED AGAINST THE CURRENT HEAD, because a regen repair has a shrinking
validity window — main moved from ac9e010 to f04b9c0 while the first loop ran,
and authority merges can invalidate a fixed point without touching a line of
it. Re-run on f04b9c0 with this patch applied: round 1 rc=0,
first_generation_equal=true, nothing further adopted. So three lines is the
complete fix against the head this lands on, not merely against the head it was
computed on.

WHAT THIS DOES NOT CLAIM. A regen fixed point says the emitter reproduces
itself. It does not say the generated tree compiles or behaves correctly —
those are separate predicates with separate evidence, and nothing here bears on
them.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01DhAfyPkuxnjZaTzPn5PyE1

[gunbai-bot]

Closing as a duplicate of #8953, which is earlier, byte-identical, and better documented.

gh pr diff on both PRs returns identical output — same file, same three receivers, +3/-3. bold-crane-441 got there about an hour before the operator asked me to fix main, and I did not know this PR existed when I started.

#8953 carries everything this body carried and states the load-bearing part more sharply: the rebuild between passes, and why re-verifying with the pre-install binary produces a green indistinguishable from a real fixed point. It also measures the reach by adopting every differing candidate rather than the file it predicted, which is the difference between "the reach is one file" and "I only looked at one file".

I have added to #8953 the two things this lane had that it did not: main's own completed CI run bisecting the red (32603243451 FAILURE at 1caf8d5, 32603180703 SUCCESS at its parent), and the re-verification against the newer head after main moved mid-run.

Merge #8953. Nothing here is lost by closing this.