test: run the selftest under an lpack-shaped string.pack

[derek-miller]

Follow-up to #31, taking the gap named in its review: nothing in this repo's CI could see FL-20, because no matrix interpreter has Control4's string.pack dialect (5.1/5.2/LuaJIT have none, 5.3/5.4 have the real one), so v0.6.8 shipped to a controller with every leg green.

• test/lpack_stub.lua: lua-bitn's lpack-shaped string.pack/string.unpack, as measured on the dev controller.
• test/lpack_test.lua: installs it before require("protobuf") and runs pb.selftest(). Discovered by run_tests.sh like the other suites; @test-modes native, since the math mode is irrelevant here.
• CLAUDE.md lists the suite.

Against the v0.6.3 vendor (the v0.6.8 tree) it fails with unsupported code '4'; with v0.6.4 it passes on Lua 5.1, 5.4 and LuaJIT 2.1. Test-only, nothing ships; no release needed.

[svc-finitelabs]

Approving. Test-only, CI 8/8 green at 1386009, and I re-ran the discrimination claim rather than taking the body's word for it.

The suite discriminates, measured as a 2x2. {vendor bitn v0.6.3 (the v0.6.8 tree), v0.6.4} x {stock string.pack, the lpack stub}, repeated on Lua 5.5, Lua 5.1 and LuaJIT 2.1:

• v0.6.3 + stock: pass, 265/265
• v0.6.3 + lpack: fail, lpack_stub.lua:61: lpack stub: unsupported code '4'
• v0.6.4 + stock: pass, 265/265
• v0.6.4 + lpack: pass, 265/265

Same verdicts on all three interpreters. The stock column passing on both vendors is the part that matters: the failure comes from the dialect, not from the stub breaking everything in sight. Output is deterministic, identical md5 over three consecutive runs, so the pass is not an ordering artifact.

The @test-modes native exclusion is empty, not merely cheap. I ran the fallback cell anyway, math.frexp/math.ldexp cleared, on 5.1 and LuaJIT against both vendors: identical verdicts, same 265 assertions. The lpack path runs through the bit32/bit64 byte helpers at vendor/bitn.lua:1215-1275 and 2159-2228, which the float codecs reach the same way in either math mode. So the second mode doubles the runtime and adds no coverage, which is a stronger claim than "the math mode is irrelevant here" and worth having measured.

The suite really executes on the legs I cannot run locally. A new suite can go green by never running, so I pulled the job logs rather than reading the check conclusions: Selftest under lpack (math native): ALL TESTS PASSED appears in Lua 5.2, 5.3 and luajit-2.0, each reporting ALL MODULES PASSED: 8/8.

The stub is byte-identical to lua-bitn's, sha256 7c3835f1e8ca4a052ee6508ff6e6616f1859e57360dd89233ed47c79eb46d776. Right call over re-deriving it: one measurement of the controller's dialect, one instrument, no drift between the repo that fixed this and the repo consuming the fix. Nothing asserts the two stay in sync, so if the dialect is ever re-measured in lua-bitn this copy goes stale quietly while still reading as "as measured on a controller". Not worth a check today, worth knowing.

Locally clean: make format-check, make typecheck (14 files, no problems), and ./run_tests.sh lpack discovers and labels it correctly. luacheck only lints src/, so the stub's string.pack assignment is outside its scope and cannot trip it.

One residual, for a follow-up rather than this PR. This closes the blind spot for the source tree. It does not close it for the artifact that actually shipped broken. grep -rn 'portable\|build/protobuf' test/ run_tests.sh returns nothing: no suite loads an amalgam, so build/protobuf-portable.lua never runs pb.selftest() at all, under the stub or otherwise. The Build Combined Module job's Verify build step checks the file exists and greps it for Protobuf, which is a presence marker rather than a behavioural check. Verifying v0.6.9 meant downloading the release asset and running the 2x2 against it by hand, which is precisely the job a suite should be doing. Loading build/protobuf-portable.lua under this same stub after make build would make that automatic, and it is the half of the FL-20 gap that is still open.

One caveat on the artifact: the APPROVED state this produces is the bot's own, not a human sign-off, so it should not be read as clearing the merge gate by itself. Not merging.