chore(frontend): consolidate duplicate vitest config files

[Rafiat30]

Closes #1281

Problem

frontend/vitest.config.ts and frontend/vitest.config.mts both existed at the same time, with different settings:

• vitest.config.ts: environment: 'happy-dom', setupFiles: ['./src/__tests__/setup.ts'], an include pattern, and coverage thresholds (functions: 18, lines: 18).
• vitest.config.mts: environment: 'jsdom', setupFiles: ['./src/test-setup.ts'], a @vitejs/plugin-react plugin, resolve.alias['@'], no coverage thresholds.

Vite/Vitest's config resolution is extension-order dependent, so it wasn't obvious which file vitest run (invoked by frontend/package.json's test script, and by npm test --workspace=frontend) actually picks up — silently changing test environment or disabling coverage enforcement for the whole team if someone edited the wrong file.

How I verified which config is actually active

I did not rely on documentation of Vite's resolution order — I verified empirically:

1. Added a unique console.error('DEBUG_MARKER: vitest.config.ts IS BEING LOADED') to the top of vitest.config.ts, and a matching DEBUG_MARKER: vitest.config.mts IS BEING LOADED to the top of vitest.config.mts.
2. Ran cd frontend && npx vitest run 2>&1 | head -40.
3. Only DEBUG_MARKER: vitest.config.ts IS BEING LOADED printed. The .mts marker never appeared, confirming Vitest 3.2.7 resolves vitest.config.ts over vitest.config.mts in this repo.
4. Removed both debug lines before finalizing.

This matches independent evidence from the codebase itself:

• src/__tests__/setup.ts (referenced by the .ts config) exists and is used; src/test-setup.ts (referenced by the .mts config) also existed but was a byte-identical duplicate, orphaned once the .mts config is removed.
• The actual test layout (32 test files) lives both directly under src/__tests__/** and colocated throughout src/** (e.g. src/lib/*.test.ts, src/components/*.test.tsx, src/hooks/*.test.tsx). The .ts config's include: ['src/__tests__/**/*.{test,spec}.{ts,tsx}', 'src/**/*.{test,spec}.{ts,tsx}'] matches this; the .mts config had no explicit include (relying on Vitest's default), which happens to also match, but the .ts config's pattern is intentional/explicit and correct for this layout.

What changed

• Removed frontend/vitest.config.mts (jsdom environment, @vitejs/plugin-react plugin, no coverage thresholds — confirmed not the active config).
• Removed frontend/src/test-setup.ts — only referenced by the now-removed .mts config, byte-identical to src/__tests__/setup.ts, so nothing was lost.
• Kept frontend/vitest.config.ts unchanged — it already had everything needed: happy-dom environment, the correct setupFiles, the include pattern matching the real test layout, coverage thresholds, and resolve.alias['@'] (used throughout the codebase for imports).
• Not carried over: the @vitejs/plugin-react plugin from the removed .mts config. This project is a Next.js app (not a standalone Vite app), and the full test suite (32 files, 286 tests) already passes without it — Vite's default esbuild JSX transform handles the .tsx test files fine for these happy-dom-based unit tests. Called out here explicitly per the acceptance criteria, since it's the one thing from the losing config not merged in.
• Added frontend/src/__tests__/vitest-config.test.ts — a small regression-guard test asserting exactly one vitest.config.* file exists in frontend/, so this ambiguity can't silently reappear.

Testing

• cd frontend && npx vitest run — 32 test files, 286 tests, all passing.
• cd frontend && npx vitest run --coverage — 32 test files, 286 tests, all passing; coverage thresholds satisfied (measured ~36.8% lines / ~58.7% functions vs. the enforced 18%/18% minimums). Ran this twice to confirm stability; one earlier concurrent run (while other background installs were competing for CPU on the shared dev machine) showed 2 tests timing out under system load — those are pre-existing real-timer-based tests unrelated to this change, and they pass reliably both in isolation and in clean full runs.

How to test manually

npm test --workspace=frontend
npm run test:coverage --workspace=frontend   # or: cd frontend && npx vitest run --coverage

Both should report the same environment/setup-file behavior as before (only now unambiguous), with 32 test files / 287 tests (286 existing + 1 new regression-guard test) passing and coverage thresholds enforced.