docs(02): finalize parity research and validation map

.planning/phases/02-api-parity-harness-bootstrap/02-RESEARCH.md

@@ -20,6 +20,18 @@
 6. **Normalize narrowly.** Match explicit JSON paths (`*_at`, known ids, captured values) with small in-house path rules; run a shape assertion before masking. For dates require an offset `+00:00` style where the PHP contract does, including key present with `null` where recorded. Assert ids are JSON integers before masking. Preserve nil versus `[]`, tri-state bool, fixed-decimal string versus number, envelope keys, and conditional key presence. A rule can be disabled per step; a broad “ignore timestamps/ids” filter would hide these failures.
 7. **Report the whole run.** Continue after a failed comparison, but stop dependent steps within a flow after a failed capture. Print status/header/path/body differences and a route coverage table (recorded/passing/failing/unrecorded) against 154 manifest route ids. Exclude seed and client-only flows from the denominator. CLI exits nonzero on a ported failure or an unrecorded required route; app tests create one subtest per flow so `-run` can select it.
 
+## Package Legitimacy Audit
+
+All three proposed direct modules have an explicit project decision or requirement, an upstream-maintained module path, and a narrow use. No package in this phase is inferred from a similarly named fork or an unverified import path. Resolve versions with `go get`/`go mod tidy` at execution time, review the resulting `go.mod`/`go.sum`, and retain the existing Go 1.27 toolchain directive. Do not treat a package appearing transitively as permission to import an unrelated API.
+
+| Package | Why it is allowed | Primary-source evidence and scope | Verdict |
+|---|---|---|---|
+| `github.com/goccy/go-yaml` | D-06 explicitly selects it for the framework fixture schema; project STACK.md independently selects it for YAML parsing. | The [upstream repository](https://github.com/goccy/go-yaml) documents tagged struct encode/decode and custom marshaling. Use directly in `tide` fixture and manifest IO; test unknown-field rejection and literal block body output rather than assuming encoder defaults. | VERIFIED |
+| `github.com/testcontainers/testcontainers-go/modules/postgres` | QA-03 explicitly requires integration tests on testcontainers Postgres; Phase 2 D-12 requires a hermetic app test. | The [official Postgres module guide](https://golang.testcontainers.org/modules/postgres/) documents `postgres.Run`, `ConnectionString`, container cleanup and snapshots. Add only to `../fonoteka.go` test code; do not add it to framework production packages. | VERIFIED |
+| `github.com/jackc/pgx/v5/stdlib` | The project already chooses Postgres/pgx via the GORM stack; the app's synthetic SQL-backed integration needs a `database/sql` driver before the real app handler exists. | The [upstream pgx `stdlib` documentation](https://github.com/jackc/pgx/blob/master/stdlib/sql.go) identifies it as the `database/sql` compatibility layer and shows `sql.Open("pgx", ...)`. Use only in the app integration test with parameterized SQL; reconcile its resolved v5 version with the app module when GORM arrives. | VERIFIED |
+
+`net/http/httputil`, `net/http/httptest`, `encoding/json`, and `database/sql` are Go standard-library packages and need no third-party install. No JSONPath or diff dependency is needed; small path and comparison code keeps the assertion semantics explicit.
+
 ## Validation Architecture
 
 - Fast checks at every implementation commit: `go vet ./... && go test ./...` in the framework root, plus the same in `../fonoteka.go` once that module has code. `go.work` does not make root `./...` traverse sibling modules; check each explicitly, as Phase 1's `scripts/check-phase1.sh` does for the hello modules.