cypress-vite 1.8.0 hardcodes `output.manualChunks = false` in its
UMD spec build config. Vite 8's Rolldown bundler rejects any
`manualChunks` value when `codeSplitting: false` is implied (which
it is for `lib`/`umd` builds), so Cypress fails to compile any spec
under our Vite 8 upgrade.

The patch deletes the hardcoded override, matching the fix proposed
upstream in mammadataei/cypress-vite#137 (open since 2025-10-28, no
maintainer response). See also mammadataei/cypress-vite#140 for the
report of the same incompatibility.

Drop this patch once cypress-vite ships a Rolldown-compatible
release.

Note for the pnpm migration:
The patch file content is portable, but the wiring is yarn-specific.
When the migration lands:

1. Copy `.yarn/patches/cypress-vite-npm-1.8.0-5384b5466c.patch`
   to `patches/[email protected]`.
2. Remove the `"cypress-vite": "patch:..."` resolution from
   `package.json`.
3. Add a `pnpm.patchedDependencies` block:

       "pnpm": {
         "patchedDependencies": {
           "[email protected]": "patches/[email protected]"
         }
       }

4. Run `pnpm install` so pnpm hashes and applies the patch.

pnpm 9+ applies patches natively; older versions need `patch-package`
as a postinstall step.

cypress-vite 1.8.0 hardcodes `output.manualChunks = false` in its
UMD spec build config. Vite 8's Rolldown bundler rejects any
`manualChunks` value when `codeSplitting: false` is implied (which
it is for `lib`/`umd` builds), so Cypress fails to compile any spec
under our Vite 8 upgrade.

The patch deletes the hardcoded override, matching the fix proposed
upstream in mammadataei/cypress-vite#137 (open since 2025-10-28, no
maintainer response). See also mammadataei/cypress-vite#140 for the
report of the same incompatibility.

Drop this patch once cypress-vite ships a Rolldown-compatible
release.

Note for the pnpm migration:
The patch file content is portable, but the wiring is yarn-specific.
When the migration lands:

1. Copy `.yarn/patches/cypress-vite-npm-1.8.0-5384b5466c.patch`
   to `patches/[email protected]`.
2. Remove the `"cypress-vite": "patch:..."` resolution from
   `package.json`.
3. Add a `pnpm.patchedDependencies` block:

       "pnpm": {
         "patchedDependencies": {
           "[email protected]": "patches/[email protected]"
         }
       }

4. Run `pnpm install` so pnpm hashes and applies the patch.

pnpm 9+ applies patches natively; older versions need `patch-package`
as a postinstall step.

(AI-generated summary; checked by @thomasheartman):

Brings the frontend onto the current Vite generation. The bulk of the
diff is sweep-mechanical (svgr import format, snapshot prefix updates)
but two upgrades introduced behaviour changes that needed code-level
adjustments.

### Headline upgrades

- `vite` 5 → 8 (Rolldown-based)
- `vitest` 3 → 4
- `@vitejs/plugin-react` 4 → 6
- `vite-plugin-svgr` 3 → 5
- `cypress` 14 → 15, `cypress-vite` → 1.8.0 (patched, see below)
- New: `@rolldown/plugin-babel`, `@emotion/babel-plugin`, `@babel/core`
- Drops `vite-tsconfig-paths` in favour of Vite 8's built-in
`resolve.tsconfigPaths`

### Code changes that were not just mechanical

- **MUI icons workaround.** Vite 8 enforces Node-style CJS interop for
ESM importers (the documented "Consistent CommonJS Interop" change).
`@mui/icons-material` 5.x has no `exports` field and would otherwise
return the raw `module.exports` object instead of the icon component. A
small `resolveId` plugin in `vite.config.mts` redirects deep imports to
the package's published `esm/` build. Drop when MUI icons is upgraded to
v6+.
- **CJS default-imports converted to named imports** for the same Vite 8
reason: `millify` (2 sites) and `react-activity-calendar` (1 site).
- **`@emotion/babel-plugin`** moved from being passed inline to
`react()` (no longer supported by `@vitejs/plugin-react` 6) into a
dedicated `@rolldown/plugin-babel` plugin in dev mode.
- **SVG imports**: `import { ReactComponent as X }` → `import X from
'...?react'` across ~50 files, matching the new `vite-plugin-svgr`
default. Also fixed a longstanding typo (`Celebatory` → `Celebratory`).
- **`tsconfig.json`**: added `"node"` to `compilerOptions.types`. Vitest
3 had been transitively pulling Node ambient types into scope; Vitest 4
stopped, leaving `process`, `global`, `NodeJS.Timeout` undeclared.
Explicit opt-in is the right thing anyway.

### Snapshot churn

All `*.snap` updates are emotion's cache-key prefix changing from `css-`
→ `mui-`, with hashes unchanged. The app already uses `createCache({
key: 'mui' })` in `ThemeProvider`; under Vite 5 / Vitest 3,
`@emotion/react` was loading as two module instances in the test env, so
the `CacheProvider` was silently bypassed and tests fell back to
emotion's default `css-` cache. Vite 8 deduplicates the dep graph
differently, so tests now match what the browser actually renders. Net:
snapshots are now consistent with prod, not regressed.

### cypress-vite patch

Cypress can't compile any spec under Vite 8 because cypress-vite 1.8.0
hardcodes `output.manualChunks = false` for its UMD spec build, which
Rolldown rejects when `codeSplitting: false` is implied. The patch
(`frontend/.yarn/patches/cypress-vite-npm-1.8.0-5384b5466c.patch`) just
deletes that override — same fix as upstream PR
[mammadataei/cypress-vite#137](mammadataei/cypress-vite#137)
(open since 2025-10-28, no maintainer activity). Reported as [issue
#140](mammadataei/cypress-vite#140). Drop the
patch when cypress-vite ships a Rolldown-compatible release.

### pnpm migration note

The patch *content* is portable, but its wiring is yarn-specific. When
the in-flight pnpm migration lands:

1. Copy `.yarn/patches/cypress-vite-npm-1.8.0-5384b5466c.patch` to
`patches/[email protected]`.
2. Remove the `"cypress-vite": "patch:..."` resolution from
`package.json`.
3. Add a `pnpm.patchedDependencies` block:
   ```json
   "pnpm": {
     "patchedDependencies": {
       "[email protected]": "patches/[email protected]"
     }
   }
   ```
4. Run `pnpm install` so it hashes and applies the patch.

pnpm 9+ applies patches natively; older versions need `patch-package` as
a postinstall step.

----

Original PR description:
> I've fixed the svgr plugin changing how it did its exports. I've not
been able to reproduce our babel config of emotion. Anyone wants to give
it a go?

---------

Co-authored-by: Thomas Heartman <[email protected]>