chore: re-vendor bitn.lua from lua-bitn v0.6.4

[derek-miller]

vendor/bitn.lua ← lua-bitn v0.6.4 release asset, copied verbatim and verified byte-identical to a local build of the tag.

v0.6.4 is v0.6.3 plus lua-bitn#23 (FL-20): string.pack/string.unpack are bound only after a load-time probe confirms the 5.3 dialect. On a Control4 controller they are lpack, so bitn v0.6.3's byte helpers raised there, and since #27 the fixed32/fixed64/float/double codecs go through those helpers: v0.6.8 raises on a controller (pb.selftest() dies in the fixed32 section). With v0.6.4 they take the byte-math path. No other change in bitn.

Verified: make check; run_tests.sh (selftest, math fallback, wire vectors, float vectors, both math modes) on Lua 5.1, 5.4 and LuaJIT 2.1; pb.selftest() on LuaJIT with an lpack-shaped string.pack/unpack installed first (the shape measured on the dev controller), which is the case v0.6.8 fails; make build. Tagging v0.6.9 on merge; the hardware end-to-end goes on the template re-vendor PR.

[svc-finitelabs]

Approving. Verified the byte-identity claim and reproduced both the controller failure and its fix against this repo's own tree.

The vendored blob is exactly the v0.6.4 asset

• vendor/bitn.lua at 7c27714: 118674 bytes, md5 ea9208120c88dd8931157658311ac94d, byte-identical to the bitn.lua asset on lua-bitn v0.6.4.
• The base blob at dfe4504 is byte-identical to the v0.6.3 asset (md5 fc52ff2a289d8de42efd271776b24b82), so the delta this PR ships is exactly v0.6.3 to v0.6.4, with nothing having drifted into the vendored copy in between.
• That delta is the whole of lua-bitn#23 and only that: probe_string_pack() plus the _compat.string_pack/_compat.string_unpack assignment, the two call-site rebinds in the byte-helper blocks (1203 and 1912 in the new numbering) from bare rawget(string, "pack") to the probed values, and VERSION v0.6.3 to v0.6.4. No other hunk.

Reproduced the break and the fix, with a control

Ran under LuaJIT 2.1 with an lpack-shaped string.pack/string.unpack installed before require, matching the shape measured on dev controller device 587: both names present, <I4 and >I4 both raise, and unpack is (data, fmt, pos) returning the position first.

tree	lpack shim	pb.selftest()
base, bitn v0.6.3	no	265/265
base, bitn v0.6.3	yes	raises at src/protobuf/init.lua:1150
head, bitn v0.6.4	no	265/265
head, bitn v0.6.4	yes	265/265

The failure is bad argument #1 to 'pack' (invalid format option 'I4'), and line 1150 is the first assert_bytes(pb.encode_fixed32(...)), so this is the fixed32 section the description names. The native no-shim control passes on both refs, so the head-plus-shim zero is a real discrimination rather than a harness that stopped asserting.

Individually, on base plus shim encode_fixed32, encode_float and encode_double all raise; on head plus shim all three return and are byte-identical to the native control output (01020304, 0000803F, 000000000000F03F).

Release scope

main is at dfe4504, which is exactly the v0.6.8 tag, and this PR is one commit, so a v0.6.9 cut after merge ships this re-vendor and nothing else.

Both build.yml and release.yml check out fresh, so build/amalg.cache is regenerated from the current tree on every build. protobuf-portable.lua, which inlines bitn rather than requiring it, will therefore carry v0.6.4, and the -i "bitn" core build excludes it as designed. No stale-amalgam path here.

CI on this head: run 34650504018, all 8 jobs green (Check, 5.1, 5.2, 5.3, 5.4, luajit-2.0, luajit-2.1, Build Combined Module).

One gap, not a blocker

This repo has no coverage for the lpack shape: git grep -iE 'lpack|string_pack|string\.pack' over src/, test/ and run_tests.sh returns nothing on this head. src/ has no direct string.pack call site, so today the whole exposure runs through vendor/bitn.lua, and lua-bitn's own suite is what asserts the probe. The consequence is that none of the six matrix legs here can detect a bad re-vendor, and v0.6.8 shipped broken to a controller with this repo's CI fully green.

test/protobuf_test.lua is already just a wrapper around pb.selftest(), so a second leg that installs an lpack-shaped stub and re-runs it is about fifteen lines, and it would have caught v0.6.8 before the tag. Happy to open that as a follow-up; it should not hold this PR, since the fix here is correct either way.

Minor and benign this time: release.yml is purely tag-gated with no needs: on the test job, so tagging v0.6.9 straight after the merge can publish before main's own matrix finishes. Same shape as the lua-bitn v0.6.4 cut earlier today. Safe here because main's tree after merge is identical to this head, which is already green.