bug: Settings page emits a 404 on every tab and renders all 306 MCP keys unpaginated

[vybe]

Summary

Two independent papercuts on the Settings page, found together:

1. Every Settings tab load emits a console error for a setting that has never been written — GET /api/settings/public_chat_url → 404.
2. Settings → MCP Keys renders all 306 keys, 294 of them inactive (96%), with no pagination and no active-only filter — ~71KB of DOM text.

Context

Found during an exploratory E2E sweep of dev @ c1cc22bc. A 31-page sweep found Settings to be the only page emitting a page-level console error, and it does so on every tab.

1. public_chat_url 404

GET /api/settings/public_chat_url
→ 404 {"detail":"Setting 'public_chat_url' not found"}

The setting is simply absent on an instance that never configured a public chat URL. The consumer treats "not configured" as an error rather than an expected empty state, so every visit logs one. It also means a genuine error on that call is indistinguishable from the normal case.

(The webhook URL builder falls back sensibly to the backend host, so there is no functional breakage — this is noise plus a lost signal.)

2. MCP Keys list is unbounded

total keys: 306
by scope:   agent 301 · system 3 · user 2
inactive:   294  (96%)

Agent-scoped keys accumulate over an instance's life (creation, rotation per #1854, ephemeral agents), and revoked keys are never filtered out of the view. The count here is inflated by test runs, but the page has no bound — this grows without limit on any long-lived instance.

Acceptance Criteria

• Loading any Settings tab produces zero console errors on an instance with no public_chat_url configured
• An unset optional setting is handled as an expected empty state, not a 404-and-log
• MCP Keys defaults to active keys, with inactive ones behind an explicit toggle or filter
• The key list is paginated or virtualised so page weight does not scale with instance age
• Empty/filtered states offer a next action rather than a dead panel

Technical Notes

• GET /api/settings/{key} returns 404 for an unset key by design; the frontend consumer should either use a defaulting endpoint or treat 404 as "unset"
• Settings → MCP Keys panel; GET /api/mcp/keys
• Consider whether the API should paginate, or whether client-side filtering is sufficient at this scale

[dolho]

/claim

[github-actions]

Claimed by @dolho. Label status-in-progress added.

Next steps:

1. Create branch: feature/2202-<short-slug>
2. Implement the feature
3. Open a PR with Fixes #2202