Fix SPU bit depth and stale JIT state

[Umberto-DEV]

Problem

The core can keep using settings or compiled code after they are no longer valid:

• SPU startup overwrites the selected audio bit depth.
• The JIT can reuse code for the wrong CPU, keep old memory links, discard unrelated code, or reload a Thumb value from the wrong address.
• A compiled block can hard-code a memory value, change that memory, and continue using the old value.
• Remapping Shared WRAM can leave compiled readers and lookup tables connected to the previous layout.

Why the existing fixes are not enough

PR #2745 and PR #2746 cover only the unrelated-code and Thumb-address errors. PR #2747 only combines those two changes. All three are closed and unmerged, and none covers the other stale-state paths.

The safeguard in 55ec724f only sees exact write addresses observed while compiling. It misses changing or conditional addresses, overlapping byte writes, and exchange instructions. The WVRAM fix in 32609bbc only covers ARM7 video WRAM, not Shared WRAM, its ARM7 alias, or both CPU lookup tables.

Fix

• Apply the existing audio bit-depth policy during SPU startup.
• Reuse compiled code only for the same CPU and remove all old memory links when mappings change.
• Select affected code using the address actually written and use the correct aligned address for Thumb reloads.
• Read values at runtime whenever a block may write memory; read-only blocks keep the existing optimization.
• Invalidate Shared WRAM users and clear both CPU lookup tables before changing the mapping.

JIT and no-JIT Release builds and all 104 focused test processes pass.

[maniman303]

So this fixes some things, as described in the description... but what really does it change / affect in day to day usage? Performance? Compatibility?

[Umberto-DEV]

For most melonDS users, these fixes will probably make no noticeable difference in everyday use.

The only directly visible change is that the DS Auto/10-bit audio setting now works correctly. The other fixes correct rare but real errors reproduced in tests, where the emulator could use old or incorrect memory data. No commercial game, crash, or general compatibility improvement has been confirmed.

These are mainly reliability fixes, not performance optimizations. One change avoids some unnecessary work, but no measurable speed improvement is claimed.

[maniman303]

Still, sounds like a great work. Thanks for reply!