ArenaLink: a queued send can be written while the port is closing #251

Found by the Codex adversarial review of Next candidate 2026-10-06 rc4 (reiserlab/webDisplayTools#247 comment). It's agreed as a follow-up after that release, not a blocker.

What happens (js/arena-link.js): close() sets _connected = false, rejects only the in-flight request, then awaits reader.cancel() before it nulls _writer. The rejection settles the caller, and _pump() then starts the next queued job. _sendOne() / _sendOneBulkRead() check only _writer, which is still set at that point. So a command queued behind the in-flight one can be written to the port during teardown. _failConnection() has the same window.

This predates the #248 lanes. The old single promise chain ran the next queued send the same way after a rejection, with the same _writer-only check. #248 kept the ordering; it didn't introduce the race.

Fix:

• _sendOne() and _sendOneBulkRead() reject with "not connected" when !this._connected || this._closing.
• close() and _failConnection() reject everything still queued in both lanes (_lanes.fg, _lanes.bg), not just the in-flight request.
• A test in tests/test-arena-link.js: queue two sends, call close() while the first is in flight, and check that the second is rejected and never written.

Related: reiserlab/webDisplayTools#248 (two-lane queue, LAB-298).