fix: add maxLength constraints to unbounded TypeBox string schemas

[birme]

Summary

Adds maxLength constraints to input TypeBox string schemas that were previously unbounded, so Fastify/AJV rejects oversized payloads with a 400 (defence-in-depth against memory exhaustion, slow queries, and oversized log entries). Closes #239.

Values follow the business-rule guidance in the issue:

• IDs / short identifiers → maxLength: 128
• Human-readable names / labels → maxLength: 200
• SDP offer blob → maxLength: 65536 (mirrors the existing SdpAnswer.sdpAnswer bound)

Response-only schemas were intentionally left unbounded (no input-hardening benefit; bounding outputs risks breaking legitimate serialization). Existing minLength/format/pattern constraints are preserved — only maxLength was added.

Touched: src/models.ts, src/api_productions.ts, src/api_ingests.ts, src/api_groups.ts, plus tests in src/api_validation.test.ts.

Note: route params hit Fastify's default maxParamLength (100 → 414) before the added 128 bound, so param-level bounds are redundant-but-harmless; the body-field bounds are the ones that produce 400s.

Test plan

• npm run lint — pass (no new warnings)
• npm run typecheck — pass
• npm test — pass (18 suites, 349 tests; +6 new tests covering oversized rejection and valid pass-through for a param, session body, and ingest body)
• prettier --check on edited files — clean

Closes #239

🤖 Generated with Claude Code

[birme]

Independent code-reviewer verdict: LGTM. Full input-field coverage verified (including Type.Omit-inherited PATCH bodies), no bound too tight for realistic input, meaningful body-field boundary tests, style adherent. Only non-blocking nits (param-level 128 bound is unreachable behind Fastify's maxParamLength=100, one weak param test, a lineId 128/200 inconsistency) — none blocking. Posted as a marker rather than a GitHub review because self-authored PRs cannot carry a state-bearing review.