Review OpenAPI drift test and response validation #61

The test suite gained two pieces of OpenAPI tooling (added under #34, commits 10a1a58 and 5491dce) that are worth a deliberate review later. Both work and pass today, but were scoped pragmatically.

• tests/test_openapi_drift.py — asserts openapi.yaml and the FastAPI apps agree on which paths/methods exist.
• tests/openapi_validation.py — ValidatingTestClient checks every test response's status code and JSON body against openapi.yaml.

Things to revisit:

1. Drift test scope. It deliberately compares path + method coverage only, not status codes or response schemas — FastAPI's generated spec is too thin for that (see the module docstring). Decide whether that is the right permanent boundary.
2. Validation approach. ValidatingTestClient is a hand-rolled wrapper using jsonschema. Consider whether a dedicated tool (schemathesis, openapi-core) is a better long-term fit, especially for request-side validation, which is currently not covered.
3. Undeclared test dependencies. This work added respx and relies on jsonschema, referencing, and pyyaml. CLAUDE.md only lists fastapi/uvicorn/httpx/pytest, and there is no dependency manifest — these should be documented (or a manifest introduced).
4. problem+json mismatch. The spec documents error responses as application/problem+json / ProblemDetail, but FastAPI actually returns application/json / {"detail": "..."}. The validator tolerates this only because ProblemDetail has no required fields. Decide whether to emit real RFC 9457 problem details or relax the spec.
5. Duplicate operationId warnings. Pre-existing: api_route declaring GET+HEAD on one function produces duplicate operationIds, visible in test output. Cosmetic.