mcp: add loopover_get_repo_settings tool mirroring GET /v1/repos/:owner/:repo/settings

[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 loopover_get_automation_state in src/mcp/server.ts — same
ownerRepoShape input, same maintainer-only auth boundary, same "thin GET proxy" shape.

Context

GET /v1/repos/:owner/:repo/settings (src/api/routes.ts) returns a repo's true EFFECTIVE
maintainer settings (gate/slop/label/surface/command-auth settings, including agent autonomy
controls) via resolveRepositorySettings, gated by requireRepoMaintainer. It is documented in
OpenAPI (RepositorySettingsSchema, registered and used in a registerPath at
src/openapi/spec.ts).

Its two closest siblings both already have MCP tools with the same maintainer-only auth boundary:

• GET /v1/repos/:owner/:repo/automation-state → loopover_get_automation_state
• GET /v1/repos/:owner/:repo/gate-config/effective → loopover_get_gate_config_effective

The /settings route itself — the raw effective settings row those two derived views are computed
from — has no MCP tool. Per the route's own comment: "/automation-state... the DERIVED view...
that /settings deliberately does not return" — /settings is its own distinct, non-overlapping
data surface, not redundant with the tools that already exist.

Requirements

• Add a new MCP tool loopover_get_repo_settings in src/mcp/server.ts, registered with the
  standard register(...) wrapper so it picks up _meta.category from MCP_TOOL_CATEGORIES (use
  "maintainer", matching loopover_get_automation_state).
• Input schema: reuse the existing ownerRepoShape ({ owner, repo }), identical to
  loopover_get_automation_state's input.
• Auth: same boundary as the REST route — maintainer-authenticated (mirror
  requireRepoMaintainer at the REST layer; the equivalent MCP-side check already used by sibling
  maintainer-only tools in this class, e.g. the pattern the getAutomationState/getGateConfigEffective
  private methods use).
• Handler: call resolveRepositorySettings(this.env, fullName) (the same function the REST route
  calls) and return its result unmodified — do not add derived fields or reshape the response; this
  tool's whole purpose is exposing the raw effective-settings row, distinct from the derived
  automation-state/gate-config/effective views.
• No OpenAPI/schema regeneration required: GET /v1/repos/:owner/:repo/settings and
  RepositorySettingsSchema are unchanged and already documented — only a new MCP tool wrapper is
  added.

Deliverables

• loopover_get_repo_settings tool registered in src/mcp/server.ts, backed by
  resolveRepositorySettings, with the same maintainer auth boundary as the REST route.
• Tool added to MCP_TOOL_CATEGORIES.
• Unit test covering the authorized-maintainer path and the forbidden (non-maintainer) path.

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 every branch
of the new tool, including the auth-rejection branch. Add a regression test asserting the tool's
output matches GET /v1/repos/:owner/:repo/settings's response shape for the same fixture repo.

Expected Outcome

A maintainer-authenticated MCP client can read a repo's raw effective settings the same way the
dashboard and REST API already can, closing the last unmirrored read in the settings/automation-state/
gate-config-effective trio.

Links & Resources

• src/api/routes.ts: GET /v1/repos/:owner/:repo/settings
• src/mcp/server.ts: loopover_get_automation_state, loopover_get_gate_config_effective (siblings to mirror)
• src/openapi/schemas.ts: RepositorySettingsSchema (already registered; reuse)

[linear-code]

JSO-6452