Fix sound Channel{1-4}.loadState slot index typo causing OOB on second loadState

[fsegouin]

Summary

A copy-paste typo in each sound channel's static loadState() method passes the runtime cycleCounter value to getSaveStateMemoryOffset() as the save-state slot index, instead of the constant saveStateSlot.

For example, in core/sound/channel1.ts:

// Before (buggy)
Channel1.cycleCounter = load<i32>(getSaveStateMemoryOffset(0x00, Channel1.cycleCounter));

// After (fixed)
Channel1.cycleCounter = load<i32>(getSaveStateMemoryOffset(0x00, Channel1.saveStateSlot));

The matching saveState() in each file already uses saveStateSlot (e.g. store<i32>(getSaveStateMemoryOffset(0x00, Channel1.saveStateSlot), Channel1.cycleCounter);), so this PR restores symmetry between save and load — it is not a behavior change, just a fix to a slot index that should always have been the constant.

All four sound channels have the same typo and all four are fixed:

• core/sound/channel1.ts — Channel1.saveStateSlot = 7
• core/sound/channel2.ts — Channel2.saveStateSlot = 8
• core/sound/channel3.ts — Channel3.saveStateSlot = 9
• core/sound/channel4.ts — Channel4.saveStateSlot = 10

Impact

After the first call to the WASM loadState(), each channel's cycleCounter holds whatever 32-bit value happened to be at offset 0x00 of an unrelated save-state region (in practice, near the start of the CPU register data). On the next loadState(), getSaveStateMemoryOffset(0x00, cycleCounter) evaluates to 1024 + 50 * cycleCounter, which can land far past the bounds of WASM linear memory and trap with:

RuntimeError: memory access out of bounds

This blocks any caller that loads more than one save state in the same WasmBoy session — for instance, an automated tool that loops loadState → run input macro → loadState → run input macro to brute-force RNG outcomes. The first load works; the second crashes the WASM module.

Diff

Four single-line changes, all of the same form (ChannelN.cycleCounter → ChannelN.saveStateSlot in the second argument of getSaveStateMemoryOffset).

Test plan

• Existing save-state tests should continue to pass (the fix only changes which slot is read; the load symmetry with saveState() was already broken, not tested).
• Verify in a host harness that two consecutive loadState() calls in the same session no longer trap.