tools: add tu_promote and tu_order_check, the TU promotion pair

[andrewboudreau]

Lifted out of the #1880 → #1882 → #1884 → #1914 promotion chain, which bundled these two tools with the manifest rows and sources they produce. The PR validator restores all of tools/ from base, so no PR in that chain could ever test its own tool change — every one of them is UNSTABLE, and #1880's PR validation failure is exactly this. Landing the tools alone, off main, lets the content PRs that follow be judged against tools that are already there.

What's here

tu_order_check.py compiles a manifest TU once and reports, per licensed function, bytes and emission order. Production isolation places an object's .text into the spanning delink in emission order, so when a TU defines its destructor out of line and mwcc emits D2, D0, D1 against the cartridge's D1, D0, the range does not link. This makes that visible before a promotion is attempted.

tu_promote.py performs the mechanical half of a promotion and guesses at nothing: collapse the per-function delinks.txt entries into one complete entry spanning the manifest's sections; git mv the src_tu/ source to its production path (R100, so credit follows); git rm every legacy_source; rewrite the entry to status: promoted; add one attribution.json override per absorbed symbol. It compiles nothing — the proof of a promotion is rombuild.py reporting 106/106 with mismatching: 0 over the whole batch.

The remaining three files are comment-only, correcting paths that promotion moves.

What is deliberately NOT carried

The chain's objisolate.py / rombuild.py / romdata_check.py deltas. They are the predecessor of the deadstrip-data work that has since landed as #1977, #1987 and #1989; main's versions supersede them. Carrying them would revert main.

Verification — against main at c05617cf2, not the chain's 350-commit-old base

• tu_promote --dry-run ov002/BlueCoinSwitch ov002/Exit ov045/PoleLift → all three resolve to their production paths; ov100/daObjPathLift_c is correctly refused as already promoted.
• tu_order_check ov002/BlueCoinSwitch ov045/PoleLift → compiles both, reports emitted D0, D1 plus an extra D2 against the wanted D1, D0.
• pytest tools/test_objisolate.py test_rombuild.py test_tubuild.py test_romdata_check.py → 107 passed.
• rombuild.py -j 16 --no-rom → 106/106 exact, 100.000000%, mismatching: 0, PASS, 7,812 ROM-data records — identical to main, as an additive tools change should be.

🤖 Generated with Claude Code

[tangos-validator]

✅ PR validation — Passed

noverify: no source/build-data changes in this PR

_{Each changed src/*.c|*.cpp is compiled and its relocated bytes compared to the binary data on a private build box. Passing requires every changed file to reproduce the ROM byte-for-byte with correct relocation targets — this catches WRONG-DEST relocations and non-reproducing near-misses that ledger-scoped linkcheck skips.}