refactor(webui): rename Overview tab to Providers

Mechanical rename: OverviewView.vue -> ProvidersView.vue (file, component
import, tab label/value in App.vue), plus doc-comment/README references
across webui/ that named the view by its old tab label.

The backend GET /admin/api/overview endpoint, adminOverviewResponse type,
and the frontend AdminOverviewResponse/dashboard.overview field all keep
their original names unchanged (API surface) -- only the UI tab label and
the component/file that renders it changed. No behavior or layout change
to the view itself.

webui/src/lib/search-expand.spec.ts

@@ -118,12 +118,12 @@ describe('an item manually opened before search, still matches, clicked closed d
 })
 
 // This module is domain-agnostic on what an "id" represents — it started as
-// OverviewView.vue's provider names, but UsageView.vue now feeds it group
+// ProvidersView.vue's provider names, but UsageView.vue now feeds it group
 // ids too (see that view's own doc comment: matchingIds there is every
 // group that matches ONLY via a member, never via its own name). These two
 // cases exist to pin that the module behaves identically for that second
 // domain, not because anything here differs by id shape.
-describe('generic ids (Usage group ids, not just Overview provider names)', () => {
+describe('generic ids (Usage group ids, not just Providers provider names)', () => {
   it('auto-expands and can be collapsed/overridden identically for a group id', () => {
     const state = newState()
     const matches = ['team-a']

webui/src/lib/search-expand.ts

@@ -1,6 +1,6 @@
 /**
  * Pure expand/collapse state for a search-filterable shadcn-vue Accordion —
- * shared by OverviewView.vue (providers) and UsageView.vue (groups), and
+ * shared by ProvidersView.vue (providers) and UsageView.vue (groups), and
  * generalized (originally provider-expand.ts) so both consume ONE tested
  * implementation instead of two copies of the same logic (vue.md: "if
  * you've written it twice, you owe an abstraction"). Extracted out of the
@@ -10,7 +10,7 @@
  * directly, including the full flagged sequence.
  *
  * Two sets track state, keyed on each accordion item's own string id (a
- * provider name in Overview, a group id in Usage — this module has no
+ * provider name in Providers, a group id in Usage — this module has no
  * opinion on what the id means or on what counts as a "match"; callers
  * decide that and pass the resulting id list in):
  * - manuallyExpanded: items the user explicitly opened, independent of any
@@ -34,7 +34,7 @@ export interface ExpandState {
  * manuallyExpanded plus every id in matchingIds that is not in
  * manuallyCollapsed (auto-expand every match, unless the user explicitly
  * closed that one). The caller decides what "matching" means for its own
- * view, and this module has no opinion on it either way — OverviewView.vue
+ * view, and this module has no opinion on it either way — ProvidersView.vue
  * passes every provider that itself matched at all (every match there
  * implies at least one matching model, so every match auto-expands);
  * UsageView.vue instead passes only the subset of its own matches that

webui/src/lib/usage-search.ts

@@ -6,7 +6,7 @@ import type { AdminUsageEntryView } from '@/types/api'
  * identical semantics, ONE implementation — no second copy of this logic).
  *
  * Every `query` parameter here is expected to already be trimmed and
- * lowercased by the caller, mirroring OverviewView.vue's own
+ * lowercased by the caller, mirroring ProvidersView.vue's own
  * normalizedQuery convention (modelMatches/aliasMatches there never
  * re-normalize either) — these functions stay pure string/array
  * operations, with the caller owning the single source of truth for "is a