Phase 4: goscan — Go analyzer born in the monorepo

Create `goscan/`, a Go-language analyzer built on `core/` from day one. This is the validation of the whole extraction (rule of three): a new language should only need the adapter layer.

Blocked by Phase 2 (#8–#11); recommended after Phase 3 (#12) so the core API is proven by two adopters.

## Adapter surface to implement (everything else comes from core)

- [ ] Parser adapter: `go/ast` (stdlib) → `core/apted.TreeNode` conversion + fragment extraction
- [ ] CFG builder for Go control flow (defer/goto/select/labeled break) targeting `core/cfg.CFG`
- [ ] `StatementClassifier`/`NoOpClassifier`, `ComplexityContributor` (short-circuit operators), Go `CostModel`, `CommentStripper` (`//`, `/* */`)
- [ ] Module resolution for the dependency graph (go.mod-aware imports; `AbstractnessFunc` = interface/exported ratio)
- [ ] Scoring policy: pick complexity/dead-code penalty formulas (start from jscan's count-ratio approach)
- [ ] CLI + report layer (reuse jscan's structure), `goscan/vX.Y.Z` release setup

## Positioning notes

- Competitor gap: staticcheck/golangci-lint don't do clone detection or health scoring; `dupl` is weak — clone detection + health score is the differentiator
- Timing is a product decision: infrastructure cost is low after Phase 2/3, so this can wait for demand signal

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by reading the Phase 2 core work and Phase 3 jscan implementation, especially core/apted.TreeNode, core/cfg.CFG, and jscan's CLI and report structure. Then map the goscan/ adapter surface around go/ast, Go control flow, go.mod-aware imports, scoring, and release setup. Done means the listed adapters, CLI, reports, and versioned release setup are implemented.

Written by the indexing model from the issue text.