Phase A's diagnosis (bit 28 of [0x40d09a40] gets set to exit
sub_822F1AA8's loop) is falsified by direct probe + --dump-addr in 4
sub-rounds.
Key evidence:
- sub_821B55D8 candidate fn fires 0× in ours; sub_824AA858
(XamInputSetState wrapper) fires 0× in canary too — chain is dead code
in both engines.
- end-of-run dump shows [0x40d09a40+0] = 0x00000021, same as at entry —
bit 28 is NEVER set.
- bcctrl at PC 0x822F1B4C (sub_822F1AA8+0xA4) fires (LR=0x822F1B50) but
the post-bcctrl BB head 0x822F1B50 fires 0× — bcctrl never returns.
- sub_82173990 (vtable[0] of singleton at [0x828E1F08]) is the call
target; tid=1 wedges inside this 768-byte function on a thread-join
to handle 0x1070 (= tid=13's thread handle).
- tid=13 (entry=sub_821748F0, ctx=0x4024a840, handle=0x1070) reaches
sub_821C4EB0 (silph::UImpl@GamePart_Title) at cycle 1882 → audit-049
cluster IS reached, wedges on handle 0x1078 there.
C.2 force-clear POC NOT EXECUTED — would be no-op since bit 28 is never
set. Per plan stopping criterion, hand back instead of proceeding blind.
Adds reading-error class #19: disasm-pattern-match without runtime
verification (Phase A scanned 49 oris-0x1000 sites and declared one the
setter without ever observing the bit get set).
No xenia-rs source changes. Canary repo also unchanged (config edit
reverted clean).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
