feat(go): build out the full Go language bundle

The Go bundle was coverage-slice-only. Because it shipped no rule files, sync-language-bundle.sh (which fingerprints a project's bundle by spotting one of its rule files in .claude/rules/) couldn't detect it, so the coverage slice it did ship never stayed in sync. Adding the rules is what makes the bundle sync-maintainable, which was the point.

Brought Go to the full tier, matching elisp:
- claude/rules/go.md and go-testing.md, the style and testing rules (table-driven tests, go test -race, errors.Is over message matching, how the coverage slice fits). These two are also the sync fingerprint.
- claude/hooks/validate-go.sh, a PostToolUse hook that runs gofmt and go vet on each edited .go file. go vet type-checks, so compile and syntax errors surface at edit time. It deliberately doesn't auto-run tests, since a package's tests can be slow or integration-tagged and shouldn't fire on every keystroke.
- claude/settings.json, Go permissions plus the hook wiring.
- githooks/pre-commit, a secret scan and a gofmt check on staged .go.
- CLAUDE.md, the seed.

validate-go.sh is TDD'd by scripts/tests/validate-go.bats: a clean file passes, gofmt and vet failures both block with the JSON payload, and non-go, missing, or empty paths are ignored. I updated install-lang.bats test 7, which asserted Go installs no CLAUDE.md, to check the full bundle instead. Verified with a real install into a throwaway project and a green make test.

1 files changed, 75 insertions, 0 deletions

diff --git a/languages/go/CLAUDE.md b/languages/go/CLAUDE.md
new file mode 100644
index 0000000..b50a05a
--- /dev/null
+++ b/languages/go/CLAUDE.md
@@ -0,0 +1,75 @@
+# CLAUDE.md
+
+## Project
+
+Go project. Customize this section with your own description, layout, and conventions.
+
+**Typical layout:**
+- `main.go` or `cmd/<name>/main.go` — entry points
+- `internal/` — packages private to this module
+- `pkg/` — packages intended for external import (only if you publish them)
+- `<package>/<file>_test.go` — tests beside the code they exercise
+- `testdata/` — fixtures (ignored by the build tool)
+
+## Build & Test Commands
+
+If the project has a Makefile, document targets here. Common pattern:
+
+```bash
+make test                 # go test ./...
+make test -- -run Pattern # match test names
+make coverage             # suite under -coverprofile + go tool cover -func
+make coverage-summary     # file-weighted total + files absent from the profile
+make lint                 # gofmt check + go vet (+ staticcheck/golangci-lint if used)
+make build                # go build ./...
+```
+
+Direct equivalents: `go test ./...`, `go test -race ./...`, `go vet ./...`,
+`go build ./...`, `gofmt -l .`.
+
+## Language Rules
+
+See rule files in `.claude/rules/`:
+- `go.md` — code style and patterns
+- `go-testing.md` — testing conventions (table-driven, `-race`, coverage)
+- `verification.md` — verify-before-claim-done discipline
+
+## Git Workflow
+
+Commit conventions: see `.claude/rules/commits.md` (author identity,
+no AI attribution, message format).
+
+Pre-commit hook in `githooks/` scans for secrets and runs `gofmt -l` on staged
+`.go` files. Activate on a fresh clone with `git config core.hooksPath githooks`.
+
+## Problem-Solving Approach
+
+Investigate before fixing. When diagnosing a bug:
+1. Read the relevant package and trace what actually happens
+2. Identify the root cause, not a surface symptom
+3. Write a failing test (a table row) that captures the correct behavior
+4. Fix, then re-run tests with `go test -race ./...`
+
+## Testing Discipline
+
+TDD is the default: write a failing test before any implementation. If you
+can't write the test, you don't yet understand the change. Table-driven tests
+express the Normal/Boundary/Error categories; details in
+`.claude/rules/go-testing.md`.
+
+## Editing Discipline
+
+A PostToolUse hook runs `gofmt` and `go vet` on every `.go` file after
+Edit/Write/MultiEdit. `go vet` type-checks, so compile errors and suspicious
+constructs surface at edit time — read them. Tests aren't auto-run on edit
+(a package's tests can be slow or integration-tagged); run them with `make
+coverage` or `go test`.
+
+## What Not to Do
+
+- Don't add features beyond what was asked
+- Don't refactor surrounding code when fixing a bug
+- Don't ignore a returned error to shorten a line
+- Don't add comments to code you didn't change
+- Don't create an interface or abstraction for a single implementation
+- Don't commit credentials or API keys — the pre-commit hook catches common patterns but isn't a substitute for care