feat: Add advanced filters panel to incident list

[spalmurray]

Adds an expandable advanced filters panel to the incident list page with filters for severity, service tier, impact type, affected service, affected region, root cause, captain, reporter, and created date range. Filters use a draft/commit pattern where selections are stored locally during editing and flushed to URL params on close. The grid layout is responsive (1 col → 2 col → 3 col). Captain and reporter filters support server-side search with infinite scroll.

[sentry]

Bug: Clicking "Clear all filters" incorrectly removes the status URL parameter, resetting the user's selected status tab to the default.
_{Severity: MEDIUM}

Suggested Fix

Update the onClick handler in FilterTrigger.tsx to preserve existing URL search parameters when clearing filters. Instead of search: {}, use a functional update like search: s => ({ ...s, ...clearedFilters }) to only remove the relevant filter keys, preserving others like status.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.

Location: frontend/src/routes/components/filters/FilterTrigger.tsx#L19-L23

Potential issue: The "Clear all filters" button in `FilterTrigger.tsx` clears all URL
search parameters by calling `navigate` with `search: {}`. When a user is on a
non-default status tab, such as "In Review", the `status` is stored in the URL. If the
user applies advanced filters and then clicks "Clear all filters", this action will
remove not only the advanced filter parameters but also the `status` parameter, causing
the view to unexpectedly reset to the default "Active" status tab.

[cursor]

PillFilter and TagFilter have heavily duplicated JSX

Low Severity

PillFilter and TagFilter share ~120 lines of nearly identical JSX (header, editing mode, display mode, dropdown, backdrop). They differ only in how individual options are rendered (Pill component vs plain text). The shared state logic is already in useFilterEditor, but the rendering duplication means any bug fix or feature change needs to be applied in both places, risking inconsistency.

Additional Locations (1)

• frontend/src/routes/components/filters/TagFilter.tsx#L39-L159

 

^{Reviewed by Cursor Bugbot for commit 19df7d2. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit a4b6bc0. Configure here.}

[cursor]

PillFilter and TagFilter have near-identical template code

Low Severity

PillFilter and TagFilter share ~120 lines of nearly identical JSX — the header, edit mode input, display mode tags, dropdown list, and backdrop overlay are all copy-pasted. The only meaningful differences are item rendering (Pill component vs plain text) and data source (static options prop vs useQuery). A single generic component accepting a renderItem callback and an options array would eliminate this duplication and ensure future fixes (e.g., accessibility, styling) apply consistently.

Additional Locations (1)

• frontend/src/routes/components/filters/PillFilter.tsx#L42-L162

 

^{Reviewed by Cursor Bugbot for commit a4b6bc0. Configure here.}