Add OpenAPI support via Huma framework

[wesm]

Summary

• Add huma/v2 dependency and define typed request/response types for all API endpoints, replacing untyped map[string]any responses with structured Go types that generate an OpenAPI spec automatically.
• Migrate all HTTP handlers from raw HandleFunc to Huma endpoints with typed inputs/outputs, pointer-based optional query params, and proper HTTP status codes. Remove old handler functions.
• Add cursor-based pagination (before parameter) to the ListJobs endpoint for efficient backward paging through large result sets.
• Add Huma endpoint tests verifying request parsing, response structure, and OpenAPI spec correctness. Fix query param handling for Huma compatibility (pointer types for optional params, sentinel values for defaults).

🤖 Generated with Claude Code

[roborev-ci]

roborev: Combined Review (ddca93f)

Verdict: One medium-severity regression was identified; otherwise the reviewed changes look clean.

Medium

• Negative query IDs can bypass the intended filtered lookup path
  • Location: internal/daemon/huma_handlers.go around humaListJobs, humaGetReview, and humaListComments; internal/daemon/huma_types.go defaults for ID, JobID, and CommitID
  • Issue: The new sentinel-based presence detection treats any negative ID other than the sentinel as if the parameter was omitted. For example, GET /api/jobs?id=-2 now falls through to the normal listing path and may return unrelated jobs, whereas the previous behavior performed an ID lookup and returned an empty result. The same applies to job_id and commit_id on the review and comments endpoints.
  • Suggested fix: Do not infer query presence from a magic numeric sentinel. Instead, detect whether the raw query key was present, track presence separately, or reject negative IDs explicitly before falling back to the non-ID path.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (495b823)

Verdict: One medium-severity regression blocks branch filtering in /api/branches; otherwise no medium-or-higher issues were identified.

Medium

• Broken repo query binding for branch listing
  • Location: internal/daemon/huma_types.go:166, internal/daemon/huma_types.go:177
  • Problem: ListBranchesInput uses query:"repo,explode", but Huma treats the full tag value as the query parameter name rather than parsing explode as an option. As a result, requests like /api/branches?repo=/path do not populate input.Repo, so the branch filter is skipped and unfiltered results are returned.
  • Fix: Change the tag to query:"repo" and add/update a test that verifies the repo filter actually narrows /api/branches results.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[wesm]

"The finding is invalid. query:"repo,explode" is the correct Huma syntax for repeated query parameters per https://huma.rocks/features/request-inputs/, and the endpoint is tested."