perf: fix top 5 high-performance-go.md violations found by codebase audit

[jeduden]

Summary

A fleet of scan agents audited internal/ and pkg/ against
docs/development/high-performance-go.md,
covering allocation/regex patterns, string/bytes handling, data-structure
layout, and concurrency/misc anti-patterns. Findings were ranked by how hot
the code path is (per-file, per-line, per-diagnostic) and whether the
benefit was empirically confirmed with a benchmark or alloc count — not
just plausible on paper. Two initially promising findings didn't survive
that check and were dropped (see "Findings considered and not taken",
below).

This PR fixes the top 5 that did survive, each with a red/green test
(a benchmark or testing.AllocsPerRun assertion that fails before the fix
and passes after) and a measured before/after number. Three rounds of
xhigh-severity adversarial code review then found and fixed a real
behavioral regression in one of the five fixes (see "Review findings",
below) plus a latent edge-case bug and a stale comment.

Fixes

1. internal/lint/file.go — ColumnOfOffset: hand-rolled backward byte
   scan → binary search reusing LineOfOffset's cached newline index.
   O(line length) → O(log newline count). Benchmarked on an 8 KB line:
   ~5.3µs/op → ~9ns/op. This function has ~26 call sites (once per
   diagnostic across many rules), so a single very long line used to make
   every diagnostic on it pay for a full backward scan.

2. internal/rules/tocdirective/rule.go (MDS035) — matchVariant:
   converted every paragraph line to a string before regexp matching, in
   both the Check and Fix paths. Switched to regexp.Match([]byte) +
   bytes.TrimRight. 6 → 0 allocs/op on the rule's alloc-budget
   fixture; the budget constant is tightened to match.

3. internal/rules/tablefmt/tablefmt.go (MDS025) — tryParseTable:
   rawLines/rows grew via plain append with no capacity hint, so a
   multi-row table paid several slice-growth reallocs. Added a
   non-allocating countDataRows pre-scan (mirroring the sibling rule
   tablereadability's established pattern) so both slices are pre-sized
   once. 174 → 162 allocs/op parsing a 52-row table (residual allocs
   are splitRowBytes's per-row cell slice, out of scope for this fix).

4. pkg/goldmark/parser/html_block.go: the type-6/type-7 HTML block
   openers called strings.ToLower(string(tagBytes)) on every trigger
   candidate line (any line starting with <). internal/lint/layer0_html.go
   already solved the identical problem with a stack-buffer lowering
   (tagBuf.lowerInto); this mirrors that pattern locally (this package
   can't import internal/lint). Confirmed 0 allocs/op for the new
   tagInAllowedSet/isRawTextTag helpers, plus a new
   TestHTMLBlock_TagCaseInsensitive integration test driving the full
   parser Open() path with mixed-case tags. Full pkg/goldmark suite,
   including the upstream-equivalence harness, still passes.

5. internal/corpus/collect.go — collectFile: used a bare
   os.ReadFile while walking cloned third-party repositories for the
   training corpus — the one file-ingestion loop reading genuinely
   untrusted external content without the byte cap every other read site
   in the codebase already applies (bytelimit, githooksync, schema).
   Now stats the file first and skips it (via reportProgress +
   return Record{}, false, nil) when it exceeds
   bytelimit.DefaultMaxInputBytes — falling through to
   bytelimit.ReadFileLimited as a second check against the file growing
   past the cap between the stat and the read. Either check failing skips
   the file; it does not fail the walk (see below for why that
   distinction needed its own fix).

Review findings (fixed during the 3 xhigh review passes)

• Corpus collection aborted the whole multi-source build on one bad
  file. The first version of fix Refactor rule management to use dynamic rule registry #5 returned collectFile's read error
  as fatal. Since collectFromRoot's WalkDir callback aborts its whole
  walk on any error, and Collect's loop over cfg.Sources returns on the
  first source error, a single oversized (or momentarily unreadable) file
  anywhere discarded every record already gathered from every source in
  the run — the opposite of resilient batch collection. Fixed in two
  steps: the stat-based size pre-check skips instead of erroring, and the
  fallback bytelimit.ReadFileLimited error (covering the TOCTOU race
  where a file grows past the cap between the stat and the read) does
  too. Added direct collectFile unit tests for both error branches, and
  rewrote the oversized-file test to use two Sources (not one) to prove
  an earlier source's records survive a later source's bad file.
• Latent negative-offset regression in ColumnOfOffset. The
  binary-search rewrite only clamped the upper bound; a negative offset
  echoed back out unclamped instead of the prior implementation's
  always-return-1 behavior. Not reachable through any shipped rule (every
  call site already guards against negative input), but fixed to match
  LineOfOffset's and the old implementation's contract.
• Stale comment in internal/linkgraph/linkgraph.go still described
  ColumnOfOffset's old O(column) backward scan after fix Add heading-max, code-block-max, and stern mode to line-length rule #1 changed it
  to O(log lines).

Findings considered and not taken

• A scan agent flagged ColumnOfOffset's backward scan as fixable via
  bytes.LastIndexByte (claimed SIMD-accelerated like the forward
  bytes.IndexByte). Benchmarking showed no measurable difference
  (~5.3µs/op both ways) — Go's bytes.LastIndexByte has no assembly
  implementation on any platform, only a plain Go loop
  (internal/bytealg/lastindexbyte_generic.go). Went with the binary-search
  fix above instead, which is a real algorithmic win.
• context.Background() created per-request in
  internal/rules/externallink/probe_net.go loses cancellation
  (Ctrl-C won't interrupt in-flight probes). Real, but the rule.Rule.Check
  interface has no context.Context parameter anywhere in its ~150
  implementations — threading one through is an interface-wide change out
  of scope for this fix set. Worth a dedicated follow-up plan.
• Struct field-reordering candidates (docHeading, heading, revMatch)
  reduce GC scan surface (ptrdata) but don't change unsafe.Sizeof, so
  there's no straightforward way to pin the improvement with a red/green
  test. Left for a follow-up that can also cover the small map[string]bool
  → map[string]struct{} set candidates found in the same pass.

Test plan

• go build ./...
• go test ./... (repo-wide, all green)
• go vet ./...
• go tool -modfile=tools/go.mod golangci-lint run ./... (0 issues)
• go test -tags goldmark_upstream ./pkg/goldmark/... (equivalence harness green; one pre-existing, unrelated failure in pkg/markdown's arena tests confirmed present on main too)
• internal/integration alloc-budget and per-rule bench-budget gates pass
• mdsmith check . — 563 files checked, 0 failures
• Codecov patch coverage: 100% (all modified/coverable lines covered)
• Each fix has its own commit with a benchmark/alloc test that fails before the change and passes after
• 3 rounds of xhigh-severity adversarial code review, each with findings addressed in a follow-up commit before the next round

🤖 Generated with Claude Code

https://claude.ai/code/session_01UCh2j2oeSw6UgNsmpjRonL

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.70%. Comparing base (d4af5d5) to head (daae490).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

Components	Coverage Δ
Go	98.69% <100.00%> (+<0.01%)	⬆️
TypeScript	99.54% <ø> (ø)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jeduden]

🟢 Merge Queue — picked up

This PR is in the queue and will be batched with other queue-labelled PRs.

Next: No action needed — you'll get another comment when CI starts on the batch. View merge queue run.

[jeduden]

🔵 Merge Queue — CI running

Merged into batch branch merge-queue/batch-754-1785006212 alongside #754, #756, #758, #762. View CI run.

Next: No action needed — you'll be notified when CI completes.

[jeduden]

✅ Merge Queue — merged

This PR landed on main via commit 47ace27. CI run that validated the merge.

Next: Done — nothing more to do here.