feat: Add Tag Filter Dropdown to Admin Settings Models Page

[silentoplayz]

Summary

The Admin Settings → Models page currently has a view filter (All / Enabled / Disabled / Visible / Hidden / Public / Private) but lacks the ability to filter models by tag. The Workspace → Models page already supports tag-based filtering via a TagSelector dropdown, but this capability is missing from the admin-facing models management page.

Problem / Motivation

Administrators managing large model libraries (100+ models) need the ability to quickly find models by tag. Tags are assigned to models in the model editor and are stored in meta.tags, but the only place to filter by tag is the Workspace Models page — which uses server-side pagination and filtering. The Admin Models page, which shows all models including non-workspace base models, has no tag filter at all.

This means an admin who tagged their models for organizational purposes (e.g., "Chat", "Embedding", "Vision", "Tools", "Completion") cannot leverage those tags when managing models from the admin panel.

Proposed Solution

Reuse the existing TagSelector component (from src/lib/components/workspace/common/TagSelector.svelte) in the Admin Models page. This component already provides the correct UX — a dropdown with tag options and a clear button.

The implementation:

1. Fetch available tags via the existing getModelTags() API during page initialization
2. Render TagSelector next to the existing AdminViewSelector in the filter bar
3. Add a client-side filter step to the reactive filteredModels computation that checks meta.tags for the selected tag
4. Reset pagination to page 1 when the tag filter changes

Files Likely Affected

• src/lib/components/admin/Settings/Models.svelte — the only file changed

Alternatives Considered

• Server-side filtering: The admin page currently uses client-side filtering (it loads all models via getBaseModels() + getModels()), so adding server-side tag filtering would require a larger refactor of the admin page's data fetching. Client-side filtering is consistent with the existing approach.
• Custom tag dropdown: Building a new tag dropdown component was unnecessary since TagSelector already provides the exact UX needed and is well-tested in the workspace context.

Additional Context

• The getModelTags() API endpoint (/api/v1/models/tags) already exists and returns a sorted list of unique tag names extracted from all accessible models' meta.tags arrays.
• Tags in meta.tags can be stored as either strings or {name: string} objects (the backend normalizes them). The client-side filter handles both formats.
• No new dependencies or API endpoints are needed — this purely reuses existing infrastructure.

---

I plan to open a PR for this once the approach is discussed. Feedback welcome!