Keep the NBCROW null bitmap on the stack (row decode perf, axis: precomputation)

[saurabh500]

Sub-issue of #247 (axis: Precomputation). ⚠️ Overlaps #197 — coordinate before starting.

Problem statement

The hot TokenType::NbcRow arm does vec![0u8; bitmap_len] per row. On the PoC benchmark that is ~1M allocate/free pairs for a value that is 6 bytes (48 columns → ceil(48/8)).

Proposed solution

Read the bitmap into a fixed-size stack array, with a heap fallback for oversized (malformed) COLMETADATA.

Feasibility: ✅ proven. Prototyped in 56a836f6, green on all six configs in #247. This is by far the cheapest item in the set.

Findings

• No plumbing and no per-result-set state is needed. SQL Server caps a result set at 4096 columns, so [u8; 512] covers every legal shape. The heap fallback exists only to stop a malformed COLMETADATA from indexing out of bounds — it is a safety valve, not a real code path.

• Only one of the two NBCROW sites can be converted. read_row_header's bitmap gets moved into RowPauseState.nbc_null_bitmap, so it must stay owned. The convertible site is the hot async TokenType::NbcRow arm in token_stream.rs.

• ⚠️ PR POC: reduce per-row cost in the TDS row decode path #238 advertises this optimization but only applies it inside its own buffered fast path. The async TokenType::NbcRow arm there still calls vec![0u8; bitmap_len]. Whoever reviews or ports POC: reduce per-row cost in the TDS row decode path #238 should verify against the async path specifically — the deck's claim overstates what the PoC actually does.

• Overlaps Sans-I/O TDS core (4c/N): invert the NBCROW null-bitmap read to sync #197, which does the same thing inside the sans-I/O stack. Either land this standalone and let Sans-I/O TDS core (4c/N): invert the NBCROW null-bitmap read to sync #197 rebase, or fold it in. Decide before starting.

Affected crate

mssql-tds

Alternatives considered

SmallVec. Adds a dependency for something a plain array plus a fallback handles.

Reuse a per-result-set scratch buffer. Needs plumbing and lifetime management for zero benefit over a stack array of a statically known maximum.

Additional context

Related but separate, and more expensive on the cursor path: read_row_header does columns.to_vec() per paused row, cloning every column_name: String. Tracked as a cleanup in #247 — far larger than the 6 bytes this item saves, though it is on the pause/resume path rather than the bulk-scan path.

Nothing here is benchmarked. This PR must carry its own measurement.

[saurabh500]

Benchmarked: small, and only on NBCROW

Measured on the feasibility spike (56a836f6, which bundles this with #256) against the preceding commit, using the in-crate decode microbenchmark described in the results comment on #247.

Case	Before (ms)	After (ms)	Δ
48 cols, NBCROW, every 4th column NULL	51.2	50.5	−1.4%
48 cols, plain ROW (control)	60.7	61.0	+0.4%
8 × VARCHAR(512), plain ROW (control)	26.4	26.0	−1.4%

The NBCROW improvement is real but small — roughly the size of run-to-run noise on a single run, and it only materialises on NBCROW-bearing result sets. The plain-ROW controls confirm no effect where none is expected.

That is unsurprising: this removes one Vec allocation per row, against the ~96 per-read allocations #252 removes. A [u8; 512] covers every legal shape (SQL Server caps at 4096 columns), so it needs no plumbing and carries essentially no risk — it is just not where the time is.

Recommendation: still worth landing — it is nearly free and removes an allocation from the hot path — but sequence it for its low risk, not for its return. Note the ⚠️ overlap with #197 flagged in #247, and that only one of the two NBCROW sites is convertible.

[saurabh500]

We wont do this. This is already addressed in #245