refactor(dashboard): extract ProviderDetailPageClient — #3501 Phase 0

[diegosouzapw]

#3501 Phase 0 — Strangler-fig decomposition of the providers/[id] god-component

First phase of the approved 6-phase plan in #3501 to drive providers/[id]/page.tsx (the repo's single largest file, 12,882 LOC) under the 800-LOC cap incrementally.

What changed (behavior unchanged)

• page.tsx → thin 9-line route wrapper delegating to ProviderDetailPageClient, matching the repo's *PageClient convention (EndpointPageClient / ApiManagerPageClient).
• ProviderDetailPageClient.tsx holds the unchanged component body. The client reads the route id via useParams(), so no props are threaded through the wrapper.
• First-ever smoke render test for the page (Hard Rule fix(oauth): prevent connection test from corrupting valid tokens #8 — the page had zero tests). Mounts the client, asserts the loading shell renders and on-mount data loading fires. This is the safety net every later extraction phase (1–6) is diffed against.
• check-file-size baseline now tracks ProviderDetailPageClient.tsx; vitest include globs the providers __tests__ dir.

Validation

• ✅ Phase 0 smoke test: 3/3 (vitest)
• ✅ typecheck:core: clean
• ✅ lint: 0 errors (3 pre-existing hook-dep warnings in the moved code)
• ✅ check:cycles: no cycles
• ℹ️ check-file-size: this change is clean; 4 unrelated pre-existing violations (usage.ts/combo.ts/accountFallback.ts/openai-to-gemini.ts) are v3.8.22-cycle drift to be re-baselined at release time — not introduced here.

Context

A contributor (@oyi77) opened #3627 attempting the same decomposition; that PR diverges from the approved plan (no PageClient wrapper, flat file layout, no hook extraction, no tests, big-bang) and is base-contaminated, so it's not merged here — but credited as co-author for the parallel effort. This PR follows the registered plan.

Part of #3501.

[gemini-code-assist]

Code Review

This pull request initiates Phase 0 of the provider-detail god-component decomposition by extracting ProviderDetailPageClient.tsx and introducing its first smoke render test. Feedback focuses on aligning with the repository's style guide by moving the newly added test file from the src/ directory into the tests/ directory, updating the Vitest configuration accordingly, and refactoring the test's asynchronous wait logic to use vi.waitFor for improved robustness.

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]

According to the Repository Style Guide (Rule 1: File Placement & Organization), all unit tests, integration tests, ecosystem tests, or Vitest files must strictly be placed within the tests/ directory (e.g., tests/unit/). They should not be created inside the src/ directory or other non-test directories.

Please move this test file to the tests/ directory (for example, tests/unit/dashboard/providers/ProviderDetailPageClient.test.tsx).

References

1. All unit tests, integration tests, ecosystem tests, or Vitest files must strictly be placed within the tests/ directory. ^(link)

[gemini-code-assist]

Since the test file should be moved to the tests/ directory per the Repository Style Guide, this glob pattern targeting src/app/**/dashboard/providers/**/__tests__/**/*.test.tsx should not be added. Instead, ensure the tests/ directory is covered by the Vitest configuration.

References

1. All unit tests, integration tests, ecosystem tests, or Vitest files must strictly be placed within the tests/ directory. ^(link)

[gemini-code-assist]

Using await act(async () => { await Promise.resolve(); }) to flush microtasks can be fragile and prone to flakiness if the component's initialization involves multiple nested promises or asynchronous steps.

Using Vitest's vi.waitFor is a more robust and idiomatic way to wait for asynchronous side effects (like API calls) to occur.

Suggested change

	// Let the mount effects schedule their fetches.
	await act(async () => {
	await Promise.resolve();
	});
	expect(fetchMock).toHaveBeenCalled();
	// Wait for the mount effects to schedule and trigger their fetches.
	await vi.waitFor(() => {
	expect(fetchMock).toHaveBeenCalled();
	});