feat(dashboard): per-provider dropdown filter on the quota dashboard

[diegosouzapw]

Summary

Port of an upstream fix by @DEYLNN, adapted to OmniRoute's TypeScript ProviderLimits and its richer existing filter UX.

The Quota dashboard (/dashboard/usage) now has a Provider dropdown alongside the existing Status / Type / Tier / Env filters. Selecting a provider narrows the visible accounts to that provider only; the choice persists in localStorage (omniroute:limits:providerFilter) and the dropdown auto-falls back to "all" when the persisted key no longer matches a connection in the current session. The dropdown only renders when there are ≥2 distinct providers in view, so single-provider setups stay clean.

What I ported vs what I skipped on purpose

Upstream PR #769 adds two things — I ported the first and intentionally skipped the second:

Upstream PR #769	OmniRoute
"All providers" dropdown	✅ Ported — added as a 5th filter dimension alongside the existing Status / Type / Tier / Env chips.
"Expiring first" sort toggle	⏭️ Skipped (SKIP-DUP) — visibleConnections in index.tsx already always sorts by status group (critical → alert → ok → empty) and tie-breaks by getSoonestResetMs within each group. Adding the toggle would either be redundant or, when off, regress the existing always-on behavior.

Implementation notes

• The provider key set is derived from sortedConnections, which is already filtered by USAGE_SUPPORTED_PROVIDERS + OAuth/api-key auth upstream, so the dropdown never lists providers the user can't actually inspect.
• Labels reuse the local PROVIDER_LABEL map (same source the existing per-card headers use), with a graceful fallback to the raw provider key.
• Sorting uses the existing i18n-aware compareTr helper from @/shared/utils/turkishText so the dropdown follows the active locale's collation.
• Provider filter is evaluated first in the visibleConnections predicate (cheapest check, prunes the largest fraction of the work).

Testability seam

Filter + option-builder logic was extracted from the inline useMemo into two pure helpers in ProviderLimits/utils.tsx:

• matchesProviderFilter(connection, providerFilter)
• buildProviderOptions(connections, compare?)

Both are exercised by 8 cases in tests/unit/provider-limits-provider-filter.test.ts (Node native test runner). This makes the predicates regression-safe without rendering React, and keeps the index.tsx useMemo a thin wire rather than the source of truth.

Test plan

• node --import tsx/esm --test tests/unit/provider-limits-provider-filter.test.ts — 8/8 pass
• node --import tsx/esm --test tests/unit/t13-stale-quota-display.test.ts tests/unit/provider-limits-proxy-fail-closed.test.ts — nearby tests still 5/5 (no regression in adjacent quota code)
• npm run typecheck:core — clean
• npx eslint on the 3 touched files (index.tsx, utils.tsx, the new test) — clean
• Manual UI check on a multi-provider setup (the dropdown's render gate providerOptions.length > 1 is only exercised live)

Attribution

• Original author: @DEYLNN (Zhen) — credited via Co-authored-by: trailer

Closes nothing (no OmniRoute issue tracks this — driven by upstream port).

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request introduces a provider dropdown filter for the quota dashboard, allowing users to filter connections by provider. It adds state management, local storage persistence, helper functions, and comprehensive unit tests. The reviewer identified a high-severity UI/state desynchronization bug where a stale provider filter loaded from localStorage could cause the connection list to appear empty while the dropdown falsely displays "All providers". A code suggestion was provided to resolve the active provider filter inside visibleConnections using the same fallback logic as the dropdown.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

There is a potential UI/state desynchronization bug when a stale provider filter is loaded from localStorage (e.g., if a provider was used in a previous session but is no longer present in the current session's connections).

In the dropdown UI, the <select> element falls back to "all" if the persisted providerFilter is not present in providerOptions:

value={
  providerFilter === "all" || providerOptions.includes(providerFilter)
    ? providerFilter
    : "all"
}

However, visibleConnections filters using the raw providerFilter state directly:

if (!matchesProviderFilter(conn, providerFilter)) return false;

This causes the list of connections to be completely empty (since no connection matches the stale provider), while the dropdown UI falsely displays "All providers" as selected.

To fix this, we should resolve the active provider filter inside visibleConnections using the same fallback logic (by checking if the filter is "all" or exists in the current connections).

Suggested change

	const visibleConnections = useMemo(() => {
	const filtered = sortedConnections.filter((conn) => {
	if (!matchesProviderFilter(conn, providerFilter)) return false;
	const visibleConnections = useMemo(() => {
	const activeProvider =
	providerFilter === "all" || sortedConnections.some((c) => c.provider === providerFilter)
	? providerFilter
	: "all";
	const filtered = sortedConnections.filter((conn) => {
	if (!matchesProviderFilter(conn, activeProvider)) return false;