Fix main: name the tubuild test's real input by symbol, not by a promoted path

[andrewboudreau]

dead references is red on main. One docstring line, and the cause is worth recording.

FAIL: 1 prose reference(s) name a path that does not exist:

  tools/test_tubuild.py
      names `src/func_ov006_020f8224.c`, which is not in the tree

Red at 6d8f8e529 — run 33378442037. Reproduced in a clean worktree at ad9dbc8c0, green after this commit.

How two green PRs made a red main

tools/test_tubuild.py landed in #2072. Its Allman-brace regression case documents the real-world input it was built from:

"""The real input: src/func_ov006_020f8224.c (ov006/dScMgMCarlo_c), whose
shadow struct puts its opening brace on the next line. ..."""

#2071 promoted that file into src/actors/dScMgMCarlo_c.cpp about an hour later. The path is gone; the prose still names it.

Neither PR could have caught this:

	when its gate ran	what it saw
#2072	before #2071 landed	src/func_ov006_020f8224.c present — reference resolves
#2071	premerge_check vs merge tree 4e0d92d28a7d	test_tubuild.py did not exist yet

Both were individually correct and 8/8 on their own merge trees. This is the merge-tree hazard one step removed: gating each PR against main does not gate a pair of PRs against each other, and the window here was 65 minutes.

I own this one twice over — I merged both, and the citation exists because my #2071 review asked for it: "Please put both failing inputs in the test file — the fix without the inputs leaves us re-deriving them next time." That was the right ask. Citing the input by path was the part that had a shelf life.

The fix

"""The real input was the legacy source for `func_ov006_020f8224`, since
promoted into the ov006/dScMgMCarlo_c TU -- named by symbol rather than by
path on purpose, because the path no longer exists and check_dead_references
reads any `a/b` token in prose as a live repo-rooted reference. ..."""

The symbol is the durable identifier: func_ov006_020f8224 survives both TU promotion and class rename, and check_dead_references only resolves a/b-shaped path tokens, so a bare symbol cannot dangle. The example loses nothing — the symbol is already asserted twice in the test body below it.

The docstring says why the path is absent. Without that, the next reader restores it as a helpful clarification and we are back here.

ov006/dScMgMCarlo_c is kept as-is: it is a/b-shaped but demonstrably does not resolve as a reference today, since it was already in the failing file and the gate flagged only the src/ token.

Verified

check_dead_references  before: FAIL: 1 prose reference(s)
check_dead_references  after : no new dead references / no broken markdown links
check_python_names     PASS   (262 files, 0 unresolvable)
test_tubuild.py        52 passed, 2 failed

Those 2 failures are pre-existing and unrelated — I measured them against the unmodified file in the same worktree and they fail identically:

test_verify_reproduces_pilot_1s_7_of_7_and_clean_objisolate
test_compile_report_matches_the_pilots_object_inventory

Both compile src_tu/actors/PoleLift.cpp for real, so they only execute on a toolchain-wired worktree — in CI they cannot run, which is why tool tests is green on main while these are red locally. Filing that separately; it is not this PR's business, but it does mean the tool tests green is hollow for those two cases.

Deliberately not bundled

--update also wants to drop a now-stale baseline entry:

- { "file": "notes/src-domain-buckets.md", "ref": "src/game/actors" }

That path exists on main now, so the baseline is carrying a dead entry that would mask a future real break at src/game/actors. Real, but unrelated cleanup in a tracked config file that every ledger PR conflicts on — and main is red right now. Separate PR.

[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.}