pc 26.3: read/write light-section masks as byte arrays, not long arrays

[DallasCarraher]

Summary

Live-testing a mineflayer bot against a real Minecraft 26.3 Realm, chunk
loading crashed in loadParsedLight/readSection with:

TypeError: The first argument must be of type string or an instance of
Buffer, ArrayBuffer, or Array or an Array-like Object. Received undefined

The light-section byte-array data (skyLight/blockLight) was coming up
short versus what the corresponding mask (skyLightMask/blockLightMask/
emptySkyLightMask/emptyBlockLightMask) claimed.

Root cause is on the wire, not in this parsing logic: decompiling the
official 26.3 server jar's ByteBufCodecs.BIT_SET (the codec Mojang uses for
these four mask fields in ClientboundLightUpdatePacketData) shows it now
calls FriendlyByteBuf.readByteArray()/writeByteArray() +
BitSet.valueOf(byte[]) - a varint-count-of-raw-bytes encoding - instead
of the varint-count-of-longs encoding every other currently-supported
version uses (cross-checked against the still-long-array-based 1.21.9/773
schema, which calls readLongArray()/BitSet.valueOf(long[]) for the same
codec).

Manually decoding a captured map_chunk packet byte-for-byte confirmed it:
reading the masks as longs produced impossible bit positions (e.g. bit 120,
for a chunk with far fewer than 120 sections), while reading them as raw
bytes lines up exactly with the real per-section light data that follows -
and with legible block-entity NBT (sign text) decoding correctly on either
side of the masks, pinning the drift specifically to these four fields.

Changes

• src/pc/common/BitArrayNoSpan.js: add BitArray.fromByteArray/
  toByteArray, matching java.util.BitSet's little-endian-within-byte
  convention (bit i is bit i % 8 of bytes[i / 8]).
• src/pc/1.18/ChunkColumn.js: use them instead of fromLongArray/
  toLongArray when mcData.version['>=']('26.3'), in both
  loadParsedLight (read, client-side) and dumpLight (write, server-side).
  Gated so nothing changes for older, already-working protocol versions.

A companion minecraft-data schema fix (the four mask fields now typed
ByteArray for 26.3, instead of an array of i64) is in
PrismarineJS/minecraft-data#1301.

This builds on the not-yet-merged 26.1-26.3 chunk-format scaffolding from
#328/#329 (26.1, merged) and #333/#331 (26.2, open) - the actual fix here is
isolated to the two files above; everything else in the diff is that
existing scaffolding.

Test plan

• Live-tested against a real 26.3 Realm: chunk light data now loads
  without throwing, and the bot reliably reaches mineflayer's spawn
  event (previously crashed hard during the very first chunk load)
• CI / existing test suite

[rom1504]

Astra agent review — AI-generated, not manually written by the maintainer.

Rechecked 7382b4f and the existing discussion.

The byte-array mask conversion is internally consistent, but this is not ready as a complete 26.3 integration yet. Earlier today boundary probes through the actual changed BitArray code passed at bits 0, 7, 8, 31, 32, 63 and 64, including empty masks and trailing-zero trimming. The paired minecraft-data #1301 head uses byte-array masks in both map_chunk and update_light.

Please coordinate that data release and rerun the failing chunk CI, then exercise the packet-to-column path. #1301 itself still has version-integration work pending. These focused mask checks are not a new captured 26.3 server fixture or evidence that every new-version packet is ready.

Skills used: prismarine-protocol-data-review checked version selection and candidate-versus-release readiness; prismarine-world-render-review checked world/renderer ownership and integration paths; prismarine-review checked current scope and existing feedback to avoid duplicate threads.