Enemy/DebuTelesa, System/MarNameRefGen_Map: include InfectiousStrings

[KakarottoCake]

Two units whose retail objects carry the four MActorMtxCalcType_* strings and the
DummyStrings.hpp pair ahead of them, byte for byte, where our sources emitted neither.
M3DUtil/InfectiousStrings.hpp exists for exactly this and pulls in
System/DummyStrings.hpp itself, in the right order.

DebuTelesa's .rodata goes from 241 bytes of missing compiler-generated constants to
24. MarNameRefGen_Map's drops to none.

Matched functions and matched data are unchanged -- 8131 and 353,763 either way. This
is source fidelity, not a scoring change. It closes the head of those two .rodata
sections so the next thing fixed in them is not sitting at the wrong offset.

Why only two

The header's TODO asks which TUs should carry these. The retail MAP answers it for 181
.cpp files -- but that is the wrong list to work from, and I want to write down why
before someone else does the obvious thing:

164 of those 181 are UNUSED with a ........ address. They were dead-stripped, so
they are absent from the extracted objects in build/GMSJ01/obj/ that objdiff actually
compares against. Adding the include to those units puts bytes in our .rodata that the
target can never contain. I tried it on 32 units first and measured it: every one of them
ended up emitting strings its target does not have.

The right list is the 142 units whose retail object still carries them. The tree
already agrees with that rule without anyone having written it down: of the 87 files that
currently carry these constants, 86 are in that set.

That leaves 56 units genuinely still to do, not 106.

Why not all 56

54 of them fail check-changed-symbol-order.py on unmodified main. CI only runs that
check on changed .cpp files, so those failures are dormant until someone touches the
file -- and a PR adding one include line to 54 of them would come back red for breakage it
did not cause. I would rather not bury a one-line change in unrelated red, so this is the
two that are clean.

Happy to do the other 54 in whatever form you prefer -- all at once with the symbol-order
noise explained, in batches, or after the ordering issues are dealt with separately. There
are 331 units failing that check tree-wide at the moment, so it is not specific to these.

mario.dol: OK. Symbol order passes on both changed files. Whole-tree clang-format clean.

[decomp-dev]

Report for GMSJ01 (825bcd1 - d8aa5e3)

📈 2 improvements in unmatched items

Unit	Item	Bytes	Before	After
mario/System/MarNameRefGen_Map	.rodata	+196	44.06%	87.94%
mario/System/MarNameRefGen_Map	TMarNameRefGen::getNameRef_Map(const char*) const	+22	69.89%	72.53%