fix(audio): bound audio-heap cache tables (SIGSEGV with large custom music packs) (#6932)

Root cause of three identical field crashes (audio thread, opcode fetch
through a pointer with its low 32 bits overwritten, seconds after scene
transitions): AudioHeap_AllocPermanent writes permanentCache[index] with
index = permanentPool.count and no bound against the 32-entry array. In
SoH every soundfont sync-load is forced permanent, and custom sequences
whose SEQ.xml says CachePolicy="Temporary" ALSO allocate permanently
(the factory stores the LUS enum where CACHE_TEMPORARY == 0, while
AudioLoad_SyncLoad's switch reads 0 with the ROM convention
'permanent'). A pack with ~60 streamed customs plus vanilla fonts pushes
count past 32 within a session, after which each allocation sprays a
{ptr, size, tableType/id} triplet at 24-byte stride through
gAudioContext - entry[135]'s ptr field lands exactly on
seqPlayers[0].scriptState.pc and entry[156] on seqPlayers[1]'s (both
verified against the crash-dump registers).

- permanentCache raised 32 -> 512 (12 KB) and AllocPermanent refuses
  allocations past the array instead of corrupting memory.
- Same unbounded-index disease fixed in the three sibling writers:
  AllocCached's persistent path (16-entry array; CACHE_EITHER degrades
  to temporary, hard persistent requests fail cleanly),
  AllocPersistentSampleCacheEntry, AllocTemporarySampleCacheEntry.
- seqLoadStatus malloc sized for the full id space (sequenceMapSize +
  0xF) matching sequenceMap; custom ids above sequenceMapSize previously
  overflowed the allocation by up to 15 bytes.

Upstream SoH bugs, not branch-introduced - this branch's many-track
packs merely made the overflow reachable in normal play. Standalone
upstreamable fix.

0 files changed, 0 insertions, 0 deletions