perf(server): default the inverted index to MaxPendingPostings=Recommended (2M)

[oc-engteam]

What

The server built core/invertedindex with a zero-value Options{}, so MaxPendingPostings was 0 = unbounded — the in-memory pending-write buffer grew until the periodic flush drained it, giving a noisy ~1.1–1.5 GiB peak build RSS at scale. This wires the production construction to pass the measured-good bound RecommendedMaxPendingPostings (2,000,000).

Why (measured)

iibench on the linux corpus (94,559 docs / 41.4M postings, 4× interleaved avg, prod default vs 2M):

	unbounded (today)	2M (this PR)
peak build RSS	~1.28 GiB (noisy 1.1–1.5)	~0.66 GiB (tight 0.6–0.7), −48%
peak Go heap	~1.15 GiB	~0.54 GiB (−53%)
build wall-time	~56 s	~62 s (+11%)
alloc traffic / GC	6.9 GiB / ~36	9.1 GiB / ~166
search / hits	~2063 µs / 2,414,505	~2140 µs / 2,414,505 (identical)

Peak build RSS is roughly halved and made predictable (unbounded is race-dependent and noisy), for a ~+11% build cost and more flush/GC churn — a deliberate memory-over-build-speed default for the possibly-small-RAM deployment target.

Scope

Consumer opt-in only. The core/invertedindex zero-value contract (MaxPendingPostings 0 = unbounded) is unchanged, so the published core module and its other consumers are unaffected — only the server sets the bound. git diff touches only internal/server/.

A newInvertedIndex constructor seam lets a light unit test capture the Options the production invertedindexInit closure passes and assert the bound (a genuine red→green guard against a silent revert to unbounded — verified: dropping the bound makes the test fail with MaxPendingPostings = 0). No on-disk change; search/hits unaffected.

Verification

Built via the full SDD flow (spec, 3 review rounds to a clean round, then workflow-driven TDD). Local gates green (go1.24.2 + go.work): build / vet / gofmt / internal/server tests; and the root go-cov gate: zero CRITICAL, total 94.0% (internal/server 95.3%).

🤖 Generated with Claude Code