openapi: pulls/:number/ai-review-findings missing from spec, unlike its maintainer-packet + reviewability siblings

[JSONbored]

⚠️ Definition of Done: this issue must be completed in full, in a single PR. Do not split this
work across multiple PRs, and do not defer any Deliverable below to a follow-up issue. A PR that
satisfies only some of the Deliverables, stubs a required test, or leaves a checkbox
partially-done does NOT resolve this issue and will be closed.

⚠️ Required pattern: mirror exactly how its two siblings on the same pulls/{number}/* path family
are already documented in src/openapi/spec.ts — /v1/repos/{owner}/{repo}/pulls/{number}/maintainer-packet
(PullRequestMaintainerPacketSchema) and /v1/repos/{owner}/{repo}/pulls/{number}/reviewability
(PullRequestReviewabilitySchema).

Context

src/api/routes.ts documents three read routes under /v1/repos/:owner/:repo/pulls/:number/*, each
backed by an MCP tool:

• .../maintainer-packet → loopover_get_pr_maintainer_packet — documented in spec.ts
  (PullRequestMaintainerPacketSchema)
• .../reviewability → loopover_get_pr_reviewability — documented in spec.ts
  (PullRequestReviewabilitySchema)
• .../ai-review-findings → loopover_get_pr_ai_review_findings (outputSchema: prAiReviewFindingsOutputSchema) — not documented; grep for ai-review-findings in
  src/openapi/spec.ts returns nothing.

The third route is the only one of the three siblings missing from the OpenAPI spec, despite
sharing the exact same path prefix, auth boundary, and MCP-tool-parity pattern as the other two.

Requirements

• In src/openapi/schemas.ts, define PullRequestAiReviewFindingsSchema as a z.object({...})
  schema, using prAiReviewFindingsOutputSchema (the raw Zod shape already validated in
  src/mcp/server.ts) as the field-level source of truth.
• In src/openapi/spec.ts, registry.register("PullRequestAiReviewFindings", PullRequestAiReviewFindingsSchema) then add a registerPath entry for
  GET /v1/repos/{owner}/{repo}/pulls/{number}/ai-review-findings, following the exact same
  request/response/tag pattern already used for the sibling .../maintainer-packet and
  .../reviewability entries immediately nearby in the file.
• Schema is the contract — regenerate and commit. Run npm run ui:openapi after the edits and
  commit the regenerated apps/loopover-ui/public/openapi.json in this same PR. CI enforces this via
  npm run ui:openapi:check (part of npm run test:ci).

Deliverables

• PullRequestAiReviewFindingsSchema added to src/openapi/schemas.ts.
• Route registered as an OpenAPI path in src/openapi/spec.ts, matching its siblings' pattern.
• apps/loopover-ui/public/openapi.json regenerated via npm run ui:openapi and committed.
• npm run ui:openapi:check passes in CI.

All deliverables are required in this one PR — there is no follow-up issue.

Test Coverage Requirements

99%+ Codecov patch target (codecov/patch, unsharded via npm run test:coverage) on any new schema
helper code. Add a regression test asserting the path appears in buildOpenApiSpec()'s output with
the correct method and a response schema whose keys match prAiReviewFindingsOutputSchema.

Expected Outcome

.../ai-review-findings is documented in GET /openapi.json / apps/loopover-ui/public/openapi.json
alongside its two already-documented siblings on the same PR-scoped path family.

Links & Resources

• src/api/routes.ts: GET /v1/repos/:owner/:repo/pulls/:number/ai-review-findings
• src/mcp/server.ts: prAiReviewFindingsOutputSchema
• src/openapi/spec.ts: /v1/repos/{owner}/{repo}/pulls/{number}/maintainer-packet and
  /v1/repos/{owner}/{repo}/pulls/{number}/reviewability registrations (exact pattern to mirror)

[linear-code]

JSO-6460