feat(models): manage model visibility from the chat selector

[AKAZIK-py]

Problem

Two long-standing gaps around the model selector:

1. Deleting a model in Settings → Models doesn't remove it from the chat selector. models.json is an upsert/override layer on top of pi's built-in provider catalogs, so a deleted entry just falls back to the built-in definition for any configured provider (Model dialog doesn't clean up enabledModels in settings.json when a connector/models are removed → persistent 'No models match pattern' warnings #560, After model deletion, the pi-web UI still displays "Model scope warnings," and the newly added Kimi K3 is not in the model dropdown list. #640). PR fix: prune removed models from enabled scope #561's implicit prune was rejected as by-design, and the supported lever — the enabledModels scope in ~/.pi/agent/settings.json — had no UI in pi-web at all.
2. The selector shows every available model with no way to hide any (feat: support hiding/pinning/filtering models in UI model selector #241, 供应商添加和模型选择问题 #324 — the filter-only half was already shipped). pi's own answer to this is the global enabledModels scope, manageable in the TUI via /scoped-models but not from the web UI.

Solution

A "Manage visible models" entry at the bottom of the chat model selector dropdown opens a dialog that edits pi's native enabledModels scope explicitly:

• Every available model listed, grouped by provider, with filter, per-provider tri-state toggles, and a global select-all
• Checkbox state starts from the models the selector currently shows (the server-resolved scope — no client-side reimplementation of pi's matching rules)
• Saving writes exact provider/modelId patterns; checking every model clears the scope back to the show-all default, so newly added models keep appearing automatically
• Scopes using globs, bare ids, or :thinkingLevel pins are flagged in the dialog before saving replaces them with the explicit list

API

• GET /api/models-visibility — raw enabledModels patterns + the full unfiltered catalog (honors project trust like /api/models)
• PUT /api/models-visibility — validated write (null clears), invalidates the models cache and is followed by a modelsRefreshKey bump so the selector reloads immediately (Saving the Models panel does not refresh the session model list (needs /reload or page reload) #822's refresh path)

Safety rails

• Empty selection rejected client-side and server-side: pi falls back to showing every model when a scope matches nothing, so saving an empty scope would silently undo the edit
• The PUT route resolves the scope before writing and refuses zero-match patterns (a stale/typo'd list can never wipe the selector)

Relation to #727

Complementary rather than overlapping: #727 adds per-provider catalog cards inside Settings → Models with segment-preserving rewrites; this PR is a lighter, in-flow entry point that manages the whole scope in one view. Both edit the same pi-native setting, so they compose. Happy to rework if you'd rather land only one approach — the API safety rails here (zero-match refusal) and the dialog component are reusable either way.

Verification

• npm test — 1032 pass (incl. new lib/model-visibility.test.mjs and components/ModelVisibilityDialog.test.mjs)
• tsc --noEmit, eslint, next build clean
• Manual end-to-end against next dev: GET/PUT round-trip writes enabledModels to settings.json, /api/models reflects the scope immediately (cache invalidation), zero-match and empty-array PUTs return 400, null restores the file byte-identically

Fixes the hiding half of #241 / #324; gives #560 / #640 users an in-app escape hatch instead of hand-editing settings.json.