Wasm: decoder diagnostics diverge from spec wording for oversized integers and memory limits

Ten commands in the pinned wg-1.0 corpus reject the module correctly but report non-spec wording, so the corpus scores them as failures. Behavior is right; only the message differs.

zig build wasm-spec -Doptimize=ReleaseFast

binary-leb128.wast (4) — expected integer too large:

:729  got CompileError: WebAssembly.Module(): memory offset exceeds address type @+32
:748  got CompileError: WebAssembly.Module(): memory offset exceeds address type @+32
:842  got CompileError: WebAssembly.Module(): memory offset exceeds address type @+34
:861  got CompileError: WebAssembly.Module(): memory offset exceeds address type @+34

memory.wast (6) — expected memory size must be at most 65536 pages (4GiB):

:52 :56 :60  got CompileError: WebAssembly.Module(): memory size exceeds address type limit @+12
:64 :68 :72  got CompileError: WebAssembly.Module(): memory size exceeds address type limit @+13

Both strings were introduced by 3d0418d4 (feat(wasm): decode and validate memory64 addresses, #296), which generalized the wording to cover both address types and in doing so dropped the spec phrasing that the 32-bit cases require. A fix likely keeps the spec text for 32-bit memories and uses the generalized text only where the address type is 64-bit.

Non-goal: changing what we accept or reject. These modules are already rejected correctly.

Umbrella: #880. Siblings: #877 (acceptance gap in the same file), #879 (behavioral).

Two different causes behind the ten:

• binary-leb128.wast:729/748/842/861 shared #877's root cause — the offset decoded as u64 and then failed validation with memory offset exceeds address type instead of failing to decode with integer too large. Fixed by reading the offset at the address type's own width.
• memory.wast:52-72 was genuine wording. 32-bit memory limits now report memory size must be at most 65536 pages (4GiB); 64-bit memories keep the generalized text, which is accurate for them.

One nuance left deliberately unaddressed, noted in the commit: the memory.wast six are assert_invalid, and we reject them during decode rather than validation. The corpus matches on the message so it cannot see the phase difference, and restructuring decode/validate for it would be a much larger change with no behavioural gain. Reopen if that phase distinction is wanted.