build: cap function size, complexity and method surface

[OmarAlJarrah]

Closes #83. Closes #178. Stacked on #225 → #223 → #222 → #221 → #220 → #219 → #218.

Summary

Three shapes produced the god object, and none of them was measured while it was growing. This enforces all three, now that the restructuring has finished and the caps can be calibrated against the shape they are meant to hold rather than the one that failed.

funlen adopts the styleguide's 70-line cap, which until now was declared in CLAUDE.md and enforced by nothing. gocognit caps nesting-weighted complexity — the reason the line cap is 70 and not 200. Both skip test files: a table-driven test is long because its table is long, and the table is data; splitting one to satisfy a size cap moves cases away from the assertion that reads them, which is the opposite of what the cap is for.

The method cap is the one that would have caught the actual failure. No function in compilers/openapi ever came near 70 lines — #178 measured that when it was filed. What grew was type surface, from one method to 159, and nothing measured type surface. A new AST rule in internal/archtest caps methods per type under compilers/ at 20, against a finished tree whose widest type is compile.Types at 14.

gocognit's first finding was a real one, and I took it rather than tuning it away. irverify's reflect walk scored 28 — twice anything else in the repo, the next being 14. Setting the bar at 30 would have made the tree pass while encoding exactly the shape the cap exists to prevent, which is the failure mode #178 names in its own sequencing note. So the walk is split: a small valueWalk value carrying the seen-set, the visitor and the truncation flag, with walk, descend and children as methods. Behaviour is unchanged; the tree's worst is now 14 and the cap sits at 20.

Test plan

• gofmt, go vet, golangci-lint run (0 issues), go build ./..., ./scripts/check-coverage.sh — all pass. Statement count moves 4188 → 4185: the three closure assignments in the reflect walk became method declarations.
• The diagnostic stream is byte-identical to main over all 163 fixtures, and the whole suite passes, which is what holds the walk split to "behaviour unchanged".
• Both caps proven by planting, per archtest: cap methods per type so the god object cannot regrow #178's acceptance. A 75-line function fails funlen at 74 > 70. Giving lowering.Ctx a twenty-first method fails the new rule with lowering.Ctx has 21 methods. Both restored, both green again.
• The counter has its own planted tests, because the live tree has nothing near the limit and a counter that always returned zero would pass the live check forever: a package past the cap, two same-named types in different packages counted apart, and value, pointer and generic receivers counted as one type — plus a method in a _test.go file that must not count.
• The live check requires a non-empty sweep, so a walk that stopped reaching compilers/ fails rather than passing vacuously.

Notes

• build: the documented golangci-lint gate cannot run against go 1.26.3 #61 (the gate could not run against go 1.26.3) is no longer blocking: golangci-lint 2.12.2 runs clean here. This PR does not close it — that issue is about the toolchain pin, not about these linters.
• statements is left off in funlen. Two limits on the same axis means the tighter one is the rule and the other is noise.

[OmarAlJarrah]

Force-pushed after a deeper review pass.

Splitting the reflect walk moved its cycle guard into a struct field, and nothing held that guard. Removing if w.seen[p] { return } changed nothing any test observed — no document in the corpus shares a pointer, because a compiled Document is a flat registry referenced by ID rather than by aliasing. A planted document that does share one now holds it, and removing the guard fails that test. Visiting a shared pointer once is also what makes the walk's paths deterministic, which invariant 7 rests on.

The rest of the PR was re-probed rather than re-read: gocognit fires at the configured 20 (not merely at the 28 it found on the old walk), funlen fires at 71 lines, the method cap fires on a twenty-first method, and the byte-sequence skip in the walk is still held by its own test.

[OmarAlJarrah]

Rebased onto the new main (the #225 squash), which clears the conflict. Then a deeper pass. The caps all still fire — funlen on a 74-line function, gocognit on a planted 48, the method cap with lowering.Ctx has 21 methods — so this is about what they measure.

The method cap counts declared methods, not the method set, and nothing said so. A type declaring 15 methods and embedding another with 15 has a surface of 30 and passes. I planted exactly that to confirm it.

That is the right measure, not a hole, and the const now says why: the dimension the failure actually grew in was declarations — 159 of them, written across 11 files, one at a time — and it is what an AST rule can measure without standing up a type checker, which is what #178 asked for. It also means the cap can be satisfied by embedding, and that is the refactoring it exists to prompt rather than a way around it: two types each under the cap, each with a coherent set, is the outcome you want. A type reaching for embedding to duck the number is visible in review in a way that one more method on one more struct never was. There is a planted case pinning the behaviour so the choice cannot change silently.

What was already sound, probed rather than assumed:

• Cross-file aggregation is held — the thing that matters most here, since the god object was spread over 11 files. Making the counter reset per file fails the planted tests.
• The test-file exclusion, and value/pointer/generic receivers counting as one type, are each held by their own planted case.
• The linter exclusion is scoped to _test\.go only: internal/testspec/spec.go is still linted, so a production file with "test" in its path does not slip through.
• The reflect-walk split is behaviour-neutral and its invariants have teeth: removing the cycle guard fails (the test added in the earlier pass), removing the byte-sequence skip fails, and dropping the truncation flag fails four tests. The depth cap's test derives its document from maxWalkDepth rather than restating 4096, so the constant cannot drift away from the test that exercises it.

Unrelated, filed on #59: the coverage gate reported two different statement counts for the same commit while I was running it repeatedly across this stack — cover.out is a fixed path and concurrent runs can duplicate blocks. It cannot cause a false pass (verified), so it is a reporting defect.