refactor(forntend): improve providers table (#5033)

# Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

## Type of change

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

## Checklist:

- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes

Author: jog1t

frontend/CLAUDE.md

@@ -1,4 +1,8 @@
 # Frontend
 
-- When building new UI components, ship a Ladle story alongside the component (`*.stories.tsx` next to the source). Cover the meaningful states (empty, loading, error, success, edge cases) so the component can be reviewed and iterated on in isolation without booting the whole dashboard. Run with `pnpm dev:ladle` from `frontend/`. Existing example: [src/app/runner-pool-error-popover.stories.tsx](src/app/runner-pool-error-popover.stories.tsx).
+- Ship a Ladle story alongside any new UI component, but only when the story would teach something a reader can't see from the component's source or the design system's existing stories. Run with `pnpm dev:ladle` from `frontend/`. Existing example: [src/app/runner-pool-error-popover.stories.tsx](src/app/runner-pool-error-popover.stories.tsx).
+  - **Story the integration unit, not the wrapper.** If a component is a thin wrapper over a primitive (e.g. a `<Badge>` with three label variants), do not write a story for it — story the parent that combines it with other state. The interesting states live where data shapes interact: row + cell + tooltip, form + validation + submit. A trivial wrapper's "three near-identical renders" is noise, not coverage.
+  - **Drive stories from realistic data fixtures, not prop permutations.** Build fixtures that mirror real API responses (empty result, single item, multi-region, partial failure, mixed kinds). Each story should answer "what does this look like when the backend returns X?" Listing every prop combination produces stories that pass design review but miss bugs like an empty endpoint set falling through to "Multiple endpoints".
+  - **Cover the states that produced real bugs in this component.** When you fix a visual bug, the regression case becomes a story. If you can't articulate a state that would change behavior, you don't need another story.
+  - **Skip the story if it would require mocking route loaders, auth, or the full data-provider stack.** Either refactor the component to accept its inputs as props (preferred — the story falls out for free), or test it through the parent route in the running dashboard. Do not stub `useLoaderData` / `useRouteContext` inside a story; that path rots fast.
 - HTTP responses can be mocked end-to-end in dev via MSW. Append `?mock=1` to any dashboard URL (dev only, gated by `import.meta.env.DEV` in [src/lib/agent-mocks.ts](src/lib/agent-mocks.ts)) to boot the worker. Then in DevTools / agent-browser console: `window.__rivetMock("*/actors/:id/kv/keys/*", { status: 503, body: { group: "guard", code: "service_unavailable", message: "..." } })`. Mocks persist across reloads via sessionStorage; `window.__rivetClearMocks()` resets. Use this to exercise error UIs without standing up real engine state. Prod bundle is unaffected (dynamic `import("msw/browser")` behind the dev gate).