chore: split oversized source files for maintainability #1097

Tracker for breaking up source files that have grown past the point where they're comfortable to navigate or review. None of these are bugs — the compiler builds, tests pass — but each one is now large enough that incremental work in it is slow (long-distance jumps in a single file, painful merge conflicts, hard to grep for the right helper, easy to drop a duplicate definition into a different page).

Scope criteria: file > ~6k lines AND has either (a) a single mega-function that owns most of the lines, or (b) no submodule structure at all. Files that are large-but-coherent (e.g. gc.rs, inline.rs, monomorph.rs, json.rs, stable_hash.rs) are intentionally not on this list — they're big but each has one clear concept.

Files in scope

Conventions for each split

1. Behavior-preserving only. No logic changes, no fix-while-you'''re-in-there. Splits should be reviewable by git diff -M -C showing pure moves.
2. Keep public surface stable. Re-export from the trunk file (pub use submodule::*;) where outside callers depend on the symbol, so downstream crates don'''t churn.
3. Land in stacked PRs, not one mega-PR. Each child issue can land in 1–N PRs as the author sees fit.
4. Version bump per merged PR as usual (see CLAUDE.md workflow). Changelog entry should call out "no behavior change, pure refactor."
5. Run the full parity suite (./run_parity_tests.sh) and cargo test --release --workspace --exclude perry-ui-* before each PR, since several of these files are hot paths in the compile pipeline and a typo can be hard to spot.

No deadline. This is opportunistic cleanup — pick one off when you'''re already touching the file for a feature/bug and the split is cheaper than another N00-line addition.