fix(msan): five "stack-overflow" suites were hiding two uninitialized reads

[DeusData]

The MSan lane excluded five suites for "stack-overflow under instrumentation". That was never deep recursion. MSan was crashing while it reported real uninitialized reads. This PR fixes the two reads, makes the reports print, and puts the five suites back in the lane. Follows up on the finding in #2583.

What was hiding

suites	read	fix
grammar_labels, grammar_probe_e, grammar_regression, lang_contract	tree_sitter_wit_external_scanner_create() returns void * but had an empty body; the runtime stores the garbage as the scanner payload (UB, C11 6.9.1p12; hidden by the vendored -w)	return NULL; plus a row in MANIFEST.md's local-patch table. Upstream bytecodealliance/tree-sitter-wit still has it at 059bfdd1af72
pipeline	githistory_coupling_limits_output filled its commits' files and count but never their timestamp, which cbm_compute_change_coupling reads (pass_githistory.c:304)	the test's stack array is zero-initialized; production's commits are already zeroed

Why it looked like a stack overflow

• Every abort was on the main thread. MSan's T<n> is the OS thread id, and it equalled the pid in all five x86-64 aborts (CI job 91868259558, 2026-08-04, the last run without exclusions). The old notes read it as a worker-thread ordinal, so the worker-stack knob, MSAN_ORIGINS and CBM_WORKERS=1 could never change anything.
• With the default slow unwinder (in this image the MSan-instrumented libunwind), reporting a read exhausted the main thread's 256 MiB stack, and the overflow handler then died with "nested bug in the same thread". fix(rst): a section's text no longer reads an unwritten byte #2583's address and today's are both a few hundred bytes past the 256 MiB limit that msan.sh sets.
• The two runs below are on the same tree and test, grammar_label_goldens.

MSAN_OPTIONS	result
default (slow unwind)	stack-overflow on address 0xffffeffffef0 ... T627, then nested bug in the same thread
fast_unwind_on_fatal=1	use-of-uninitialized-value at wit/scanner.c:13:54, with a full stack

Lane changes (scripts/msan.sh)

• MSAN_OPTIONS defaults to fast_unwind_on_fatal=1. The build already keeps frame pointers.
• MSAN_EXCLUDE is down to cli, whose install-path failure is a separate cause that is still undiagnosed.
• Rewritten to match what is true:
  • the known-red block;
  • the header, which still said CI runs without exclusions;
  • the MSAN_ORIGINS and stack comments.
• The "PARTIAL lane" warning and the exclude-name typo check sat in a branch behind elif true and never ran. They now run in the per-suite path. The check is a case match, not a grep -q pipe, which pipefail can misreport.
• Comment-only: scripts/ci/msan-lane.sh and the comment above the test-msan job in .github/workflows/_test.yml no longer say the five suites overflow. No job or step changes.

Checks

• Local arm64 MSan (docker compose … run --rm test-msan, the real msan.sh with its new defaults), on the five formerly excluded suites:

  • before each fix: grammar_labels reported wit/scanner.c:13, and with WIT fixed, pipeline reported pass_githistory.c:304;
  • after both fixes: 442 passed, 0 failed, no MSan output;
  • rebased onto main 879c11e (after feat(docs): doc-comment links for eight more languages, diagrams and OpenAPI operations in the graph #2593, which also changed test_grammar_labels.c and test_pipeline.c): 443 passed, 0 failed, no MSan output.

• macOS ASan, the same five suites: 441 passed, 0 failed.

• make lint-ci is clean. scripts/security-vendored.sh passes with the two updated checksums (wit/scanner.c and MANIFEST.md).

• PR CI is the gate. The lane selector puts this PR in T5-core (workflow and vendored paths), so test-msan runs on x86-64.

• Local legs skipped: the full 3-OS ladder. The C changes are a one-line return in a vendored scanner and a test initializer, so a platform-specific failure is unlikely.