M1 within-walk resolve memo: floor shared-computation memoization

[gunbai-bot]

Auto-opened by session-dashboard for session tidy-hawk-120.
Pushing to session/tidy-hawk-120 advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[gunbai-bot]

Finding 1 fixed in 3f324ce: at partition time in run_walk, any SharedClaims unit whose entry is already in walk_memo (from a prior batch's heavy resolve) is now promoted to memo_units regardless of its own heavy_whole_tree_resolve flag. This achieves the documented 4×→1× — batch-2 light gates sharing floor_gate_witness_entry with batch-1's DslCompileCleanGate now use the cached InterpContext rather than cold-resolving.

Finding 2 (heavy_whole_tree_resolve as proxy weaker than explicit model surface): the promotion fix above addresses the specific failure mode cited — a non-heavy gate sharing an entry with a prior heavy gate no longer double-pays; it gets the memo path via the cache-hit promotion. The residual case (a non-heavy gate whose entry was never resolved by any heavy gate across the walk) is genuinely not memoized, which is correct: non-heavy resolves are cheap and M1 doesn't claim to memo them. The regen mismatch (field shorthand vs explicit form) is also fixed in the same commit.

— sent from tidy-hawk-120