Monitoring: contain failures and stop showing the raw 403 string

[posthog]

Problem

• QA users lost the whole Monitoring section to a bare "Request failed with status code 403" banner with a Retry that could never work — the section had no page-level error boundary and no 403 handling, so a permission or missing-Fleet-connection problem read as an app crash.
• api-client.ts passes the upstream body message straight through, and no layer on the Fleet path (use-policies.ts, use-queries.ts, query-state.ts) had a 403 branch, so the raw transport string reached the user.
• Separately, the active tab did not stick: switching to ?tab=queries flipped back to the policies default.

Changes

• 403 becomes a real terminal state, not a raw string. A new ForbiddenError in query-state.ts mirrors the existing OfflineError: the Fleet list hooks throw it on HTTP 403, queryState reports isForbidden, and loadErrorProps swaps in a plain-language "not available — you may not have permission, or Fleet is not connected" message and drops the Retry (a second attempt returns the same rejection).
• Failures stay contained. The shared ContentErrorBoundary now understands the same state, and monitoring/page.tsx plus its policy / query sub-routes are wrapped in it — the way scripts-v2 already is — so a failed query takes out the content region, not the app shell.
• The chosen tab sticks. The page is now the only writer of the search URL param (the tabs receive it as props). Two useApiParams instances both writing the URL let a tab's search write reassert its own stale tab snapshot, which flipped the page back to the policies default.

State	Before	After
Fleet 403	Request failed with status code 403 + dead Retry	"This section is not available…" + no Retry
Query throws	replaces the app shell	replaces the Monitoring content region only
Switch to Queries tab	flips back to Policies	stays on Queries

Why

QA sessions showed users opening Monitoring, seeing a raw error where policies and queries should be, and leaving within seconds (with rage-clicks). The section looked broken when the real cause was a permission or integration problem.

Test plan

• npm run type-check — 0 errors
• npm run lint:biome on changed files — clean
• npm run build — all /monitoring* routes build

Agent context

Considered a shared throwFleetError(res) helper and extending the fix to the detail-view react-query 403 path; both were left out — the helper is over-engineering for two call sites, and the detail 403 render path was outside the reported symptom. The boundary wrap on the detail routes stays as defense-in-depth for thrown errors, matching scripts-v2.

---

Created with PostHog Desktop from this inbox report.