feat(dashboard): surface managed pool error state on compute tab

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5417 fix(api-public): return 405 for method mismatch instead of 5 …
• #5415 feat(dashboard): surface managed pool error state on compute … 👈
• #5416 docs(website): tighten container runner intro paragraph
• main

Get stack: forklift get 5415
Push local edits: forklift submit
Merge when ready: forklift merge 5415

_{change zmknrmtp}

[claude]

Review: surface managed pool error state on compute tab

Small, focused change. The PoolErrorAlert extraction is reused cleanly between the "no config yet" early-return and the normal ComputeForm render, and the status === "error" / .error?.message access pattern matches existing precedent in images-table.tsx's ManagedPoolStatus, so the SDK types are almost certainly correct.

Possible issue: "Redeploy to retry" copy has no reachable action

The fallback message in PoolErrorAlert reads:

"The compute pool is in an error state. Redeploy to retry."

But DeployFooter (namespace-compute.tsx:462-485) only renders when isDirty || busy, and isPoolBusy (namespace-compute.tsx:257-267) does not include "error" in its status list. So when a pool is in the "error" status and the user hasn't touched any field, there is no visible "Deploy changes" / retry button anywhere on the tab. The alert tells the user to redeploy, but the only way to reveal the submit button is to make an incidental edit (which then dirties the form for an unrelated reason).

This may be intentional/out of scope if the expectation is "edit your config to fix the error, which naturally reveals Deploy changes," but for a transient/infra-side failure (no config change needed) there's currently no way to just retry the same config from this tab. Worth double-checking whether DeployFooter should also treat status === "error" as a reason to show a submit button (e.g. show the footer whenever status === "error" too, with a "Retry deploy" label), or otherwise soften the copy so it doesn't promise an action that isn't reachable.

Everything else looks solid

• No duplicate rendering: the early-return alert (isError || !pool?.config) and the in-form alert are mutually exclusive branches, so a pool with status === "error" and a present config only renders one alert.
• Alert/AlertTitle/AlertDescription and the destructive variant are correctly exported from @/components and support this usage.
• No security concerns. The error message is rendered as JSX text (auto-escaped), not injected as HTML.
• Consistent with CLAUDE.md conventions: comments are full sentences, no em dashes, no unnecessary abstraction.

Test coverage

No test/story added. Per the frontend CLAUDE.md guidance, PoolErrorAlert is arguably a thin wrapper over Alert (two near-identical text states), and NamespaceComputeContentInner/ComputeForm require the full data-provider/route stack, both of which are call-outs for skipping a Ladle story here, so this is likely fine as-is, just flagging for visibility.