Floor: pay the shared MultiEntryIndex in preparation, not in an arbitrary claim

[gunbai-bot]

Summary

• commit_witness_claim_pair_resolvable (and its two siblings ci_floor_commit_witness_claim_pairs / commit_witness_claim_roster_defects) called build_multi_entry_index directly instead of going through process_shared_index, the existing thread-local shared-index cache every other production call site already uses. Every call re-walked and re-parsed the whole witness corpus, uncached — measured 62.7-83.0s for a single call to commit_witness_claim_pair_resolvable, on a witness with a ~1-5s fast-lane budget. load_sources_for_entry had the same defect.
• Fixed the same way as Floor: pay the module-path index in preparation, not in an arbitrary claim #8470's module-path-index warm: route the four call sites through process_shared_index, and add an explicit warm call for it during run_required_floor's preparation phase, so the one-time cost is deterministically paid there instead of falling on whichever claim happens to run first.
• Does not narrow the floor roster - the roster is unchanged; only the index construction is deduplicated/relocated.

Test plan

• cargo check -p v1-compiler --bin claim_executor (local build) - clean
• cargo build --release -p v1-compiler --bin claim_executor --bin gunbc (local) - clean, verified real runnable binaries
• cargo fmt -p v1-compiler --check - clean
• cargo clippy -p v1-compiler --bin claim_executor (local, informational scope) - 38 pre-existing warnings, none in the lines touched by this diff
• Ran the specimen witness function (commit_witness_claim_roster_red_control_holds) via gunbc run post-fix - still asserts correctly (RED control on the synthetic stale pair still holds)
• Empirically verified the cache actually hits across calls in one process: a throwaway .dag file making two calls to commit_witness_claim_pair_resolvable with identical args ran in ~87s total (not ~2x the ~92s single-call cost), confirming the second call served from process_shared_index's cache instead of re-walking the corpus
• Final grep of build_multi_entry_index( confirms no remaining unfixed production call sites - only the legitimate internal build inside process_shared_index itself and pre-existing #[cfg(test)]-only sites remain

🤖 Generated with Claude Code