Compiled mapper: throw on a value not in the mappings instead of writing it

[u9g]

The compiled write/sizeOf mapper falls through to the raw value when it isn't in the mappings (mappings[value] || value), so an unmapped name reaches the underlying numeric type and serializes as NaN → 0. The interpreted mapper throws <value> is not in the mappings value on the same input; this makes the compiled one match.

Why it matters: in node-minecraft-protocol, writing a packet name that doesn't exist in the current protocol state (e.g. mineflayer's physics loop sending position while a Velocity server transfer has the client in the configuration state) serialized to a single 0x00 byte with no body. In the configuration state that's a real packet id (client_information), so the proxy fails to decode it and kicks with "An internal error occurred in your connection." With this change the write raises a serialization error instead of putting corrupt bytes on the wire.

The || value fallback also meant a value legitimately mapped to 0 only worked by accident: 0 is falsy, so the name was passed to the numeric type and happened to serialize as NaN → 0. Covered by the new test.

Read is left as is (it still returns the raw id for an unknown value), since consumers rely on receiving unknown packets rather than a parse error.

Heads-up for consumers: anything that was serializing a mapper from undefined/an unmapped value and silently getting 0 now throws. Found two in the login path and fixed them ahead of this:

• client: send particleStatus in the configuration-phase settings packet PrismarineJS/node-minecraft-protocol#1519 (particleStatus in the configuration-phase settings)
• settings: send particleStatus to the server PrismarineJS/mineflayer#4045 (same field in the play-phase settings)