schema-based request validation with bounds for routing endpoints

[mikewheeleer]

Summary

routing inputs are validated inconsistently and some bounds are missing, allowing oversized or malformed payloads through. Add declarative schema validation with explicit bounds at the boundary.

Why this matters

Unvalidated input is a correctness and security risk. Declarative schemas make the contract explicit, consistent, and testable.

Requirements

• Define request schemas for the routing endpoints with explicit min/max bounds.
• Reject invalid input at the boundary with a structured validation_error (field-level details).
• Strip unknown fields; never pass unvalidated data to the service layer.
• Behavior is otherwise unchanged for valid input.

Technical guidance

• Validate at the edge (middleware), not deep in handlers.
• Return all field errors at once, not just the first.

Edge cases — each must have a test

• valid payload -> passes unchanged
• missing required field -> 400 with field detail
• oversized string/number -> 400
• unknown field -> stripped
• wrong type -> 400

Acceptance criteria

• All requirements and every edge case above implemented and covered by tests
• New unit and integration tests; existing tests still pass and no regressions
• Structured, typed errors (no leaked internals; stable codes)
• npm run lint, npm test, and npm run build all pass locally
• Code follows the repo's existing conventions; no duplication or dead code
• Short docs/comments explaining the design and any non-obvious decisions
• PR description explains the approach and includes Closes #<issue>

Out of scope

• Cross-field business rules (service layer)
• Response validation

Rewards

Part of the GrantFox OSS / Official Campaign (FWC26) — this task may be rewarded. PR quality is assessed by AI: depth, correctness under edge cases, meaningful tests, and clean design are what earn the reward. Shallow changes (typos, formatting, trivial docs) do not qualify.