tests-golisted

# Backend tests: Go (`go test`) Go's test framework is the standard library's `testing` package; there is no framework to detect. Check whether the project uses an assertion library (`testify`, `gotest.tools`) before writing — if it does, follow it; if it doesn't, don't introduce one. ## Layout Tests live **beside the code they test**, as `<file>_test.go` in the same directory. Two package choices, and the project's existing one is the answer: - `package foo` — an internal test, with access to unexported identifiers. - `package foo_test` — an external test, restricted to the exported API. Prefer this for anything that is really testing the package's contract; it catches an API that is awkward to use. `testdata/` is ignored by the toolchain and is where fixtures belong. A test that needs a helper binary or a golden file puts it there rather than in the package directory. ## Writing - **Table-driven with subtests** is the idiom: a slice of cases, then `t.Run(tc.name, func(t *testing.T) { … })`. Subtests give each case its own name in the output and let a rerun target one of them. - `t.Helper()` in any assertion helper, so a failure reports the caller's line rather than the helper's. - `t.Cleanup(...)` for teardown registered inside a helper, or that must run after a test's subtests finish. Not because `defer` misses failures — `t.Fatal` ends the goroutine through `runtime.Goexit`, which does run deferred calls — but because a helper's `defer` fires when the