perf: fix top 5 high-performance-go violations (LSP/config/build reflect sorts + MDS005)

[jeduden]

Summary

An audit against docs/development/high-performance-go.md ran three
parallel scans: the rule packages under internal/rules/, the LSP
server plus config/index/build/export/corpus/metrics packages, and the
core engine/lint/mdtext/pkg/markdown hot path. The engine/lint/mdtext
scan came back mostly clean — that territory has already been through
several prior optimization rounds (#811, #813, #825, #828, #833, #835,
and the still-open #838) and is heavily instrumented with its own
alloc-budget gates. The rule-package scan's single standout finding
(MDS025's duplicate table-row parse) turned out to already be a tracked,
scheduled follow-up (plan 195/181, grandfathered in
internal/integration/alloc_budget_test.go at a 60-alloc ceiling) that
needs a dedicated single-table-walk refactor rather than a quick fix, so
it's left alone here. The five issues below came from the LSP/config/
build sweep, each verified red (measured allocs before the fix) → green
(after) with a dedicated test:

1. internal/rules/noduplicateheadings (MDS005, default-enabled) —
   Check's seen map started at zero capacity even though
   astutil.CollectHeadingNodes returns a slice of known length one
   line earlier. Pre-sizing it with len(headings) avoids the bucket-
   array reallocations an unsized map pays for as it grows past Go's
   load factor. This rule runs on every workspace file. 97 → 91
   allocs/op on an 80-heading fixture.

2. internal/lsp — completion.go's sortItems,
   symbols_workspace.go's handleWorkspaceSymbol, and four
   near-identical location sorts in symbols_navigation.go all used
   sort.Slice/sort.SliceStable, which drive reflect.Swapper
   internally. These run on every textDocument/completion,
   workspace/symbol, and textDocument/references request — i.e. on
   every keystroke-driven navigation or completion query in the editor.
   The four location sorts share one new sortLocationsByURIThenLine
   helper. 2 → 0 allocs/op for each extracted sort helper.

3. internal/config — kind_files.go, schema_files.go,
   convention_files.go, and wordlist_files.go each re-sorted the
   result of os.ReadDir with sort.Slice, but os.ReadDir already
   "returns the entries sorted by filename" per its own doc — the sort
   was both reflect-driven and pure dead work. Runs on every LSP config
   reload (workspace open, or a kind/schema/convention/wordlist file
   save) and every CLI config load. 1801 → 1798 allocs/op on
   discoverKinds with 20 kind files (the removed sort's own cost is
   small next to the YAML-parse work the function also does per file,
   but it's dead code and reflect-driven regardless).

4. internal/linkgraph — sortByDepthThenName used sort.Slice,
   run once per colliding-basename bucket on every WikilinkIndex
   (re)build; real workspaces with repeated basenames (README.md,
   index.md) pay it N times per rebuild. 2 → 0 allocs/op.

5. internal/build — Cache.Save's sort.SliceStable comparator
   called outputSetKey (which allocates a sorted path-slice copy and
   builds a joined string) on both sides of every comparison, redoing
   full per-entry work on every one of the O(n log n) comparisons
   instead of once per entry. Runs on every mdsmith build that
   persists the cache. Fixed with a decorate-sort-undecorate
   sortEntriesByOutputKey (each key computed once,
   slices.SortStableFunc instead of sort.SliceStable) plus switching
   outputSetKey itself from fmt.Fprintf to strconv. 5914 → 242
   allocs/op on a 60-entry cache — the largest win in this round, a
   ~24x reduction.

Each fix follows red/green TDD: a test measuring the actual allocation
count was written first and confirmed to fail against the un-fixed code
(either by running it before the fix, or by temporarily reintroducing
the old implementation), then the fix landed and the same test was
confirmed green with the real measured budget.

Deferred (out of scope for this PR)

• MDS025's duplicate table-row parse (internal/rules/tableformat):
  Check runs two independent per-line table parsers over the same
  f.Lines (tablefmt.tryParseTable and structure.findStructureTables).
  This is the single worst allocation outlier in the rule set (60 allocs
  vs. the project's 10-alloc ceiling), but it's already a tracked,
  scheduled follow-up (plan 195/181) needing a single-table-walk
  refactor across a 700+ line file — too large and too risky for a
  routine automated sweep of a default-enabled, widely-used rule.
• A handful of lower-frequency sort.Slice sites (once-per-CLI-
  invocation code in internal/corpus, internal/export,
  internal/metrics) were noted but left alone in favor of the
  higher-frequency LSP/config/build sites above.

Test plan

• go build ./...
• go vet ./...
• go test ./... (all packages green)
• go tool -modfile=tools/go.mod golangci-lint run on changed
  packages (0 issues)
• go run ./cmd/mdsmith check . (588 files, 0 failures)
• Each fix verified red (allocs measured against the un-fixed code)
  → green (fix applied, budget tightened to the real number)

🤖 Generated with Claude Code

https://claude.ai/code/session_018CxpCyTLCf454rQXN9sDMC

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.78%. Comparing base (b48e90c) to head (b351083).

Additional details and impacted files

Components	Coverage Δ
Go	98.77% <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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.