Validate incoming requests against the vendored OpenAPI specs #34

User story / Problem statement

Currently nothing validates incoming requests. The vendored OpenAPI specs are used to validate responses in tests only, so a malformed request body reaches the handler and can be forwarded to the ledger, where it fails as an opaque server error instead of a clean client error.

Expected outcome

Requests are validated against the same vendored specs that describe the responses. A malformed body or parameter is rejected with a 400 that names the offending field, before any ledger call is made. Undocumented routes such as admin and health continue to work untouched.

Acceptance criteria

• Request validation is mounted for each vendored spec, after body parsing and before the routers
• Undocumented routes pass through unaffected, proven by a test
• A malformed factory request returns a 400 naming the missing field and submits nothing to the ledger
• Validation errors serialize through the existing terminal error handler
• Test output stays clean, with no validator warnings on stderr
• The suite is green

Technical notes

The specs declare integer-width format hints that the validator's schema engine does not know, which produces a large volume of harmless warnings unless those formats are registered permissively. The width is already enforced by the integer type, so registering them permissively changes no behavior.

Unknown query parameters must be allowed. The validator rejects them by default, which is not spec-mandated and would break documented endpoints when a client appends a cache-buster or tracking parameter.

Additional context

Part of #22. Implemented by #15.