chore(deps): update npm packages within declared ranges; reformat for prettier 3.9.4

npm update brought every package to the latest version its existing package.json
range allows (Angular tooling 22.0.2/22.0.4 -> 22.0.5, prettier 3.8.4 -> 3.9.4,
typescript-eslint 8.62.0 -> 8.62.1); package.json itself needed no range changes.

Auditing actual deprecation warnings (not just outdated versions) found nothing
further to fix: @angular/platform-browser-dynamic and @angular-devkit/build-angular
are deprecated by Angular but still required peer dependencies of the latest
published @storybook/angular (10.4.6 — peer range still `>=18.0.0 < 22.0.0`,
already why .npmrc sets legacy-peer-deps); jest-process-manager/expect-playwright
are transitive-only through @storybook/test-runner's latest stable (0.24.4). No
newer version of either Storybook package exists yet that drops them. The
remaining npm audit advisory (@babel/core, low severity) is the same
already-documented, deliberately-left issue in README.md (fixing it downgrades
Angular). Left package.json's overrides untouched.

The prettier bump alone changed formatting opinions on files this session didn't
otherwise touch (a stale markdown italics marker, a few object-literal wrap
points) — reformatted everything so `format:check` (part of CI) doesn't regress.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

src/docs/machines.mdx

@@ -36,7 +36,11 @@ dispatches a message describing the outcome:
 // command = "go do it, then say what happened" — reduce never sees the HTTP call itself
 async function submit(store: Store<WizardState, WizardMsg>) {
   const r = await adapter.submit(toDto(store.model()));
-  store.dispatch(r.ok ? { tag: 'SubmitConfirmed', referentie: r.value } : { tag: 'SubmitFailed', error: r.error });
+  store.dispatch(
+    r.ok
+      ? { tag: 'SubmitConfirmed', referentie: r.value }
+      : { tag: 'SubmitFailed', error: r.error },
+  );
 }
 ```
 
@@ -60,7 +64,7 @@ worse name, and it's the thing a newcomer copies if two idioms are visible side
 Wire every machine through `createStore`, full stop.
 
 `dispatch` uses `model.update(…)`, not `model.set(reduce(model(), msg))` — the latter
-reads `model()` *inside* the call, which means an `effect()` that both reads `model` and
+reads `model()` _inside_ the call, which means an `effect()` that both reads `model` and
 calls `dispatch` would subscribe to its own write and livelock. `.update()`'s callback
 receives the current value directly, untracked.
 
@@ -73,7 +77,7 @@ receives the current value directly, untracked.
 - A top-level machine exports `initial` (the starting Model) and `reduce` — unprefixed,
   since the file/module already disambiguates them at the import site
   (`import { initial, reduce } from './herregistratie.machine'`).
-- A **composable sub-machine** — one embedded *inside* a parent Model, like
+- A **composable sub-machine** — one embedded _inside_ a parent Model, like
   `upload.machine.ts`'s upload-widget state living inside the registratie wizard's own
   Model — keeps **prefixed value exports** instead: `initialUpload`, `reduceUpload`.
   The parent machine already imports several machines' `initial`/`reduce`; prefixing the
@@ -90,7 +94,7 @@ a function of what I already have?"
 ## Where RemoteData fits in
 
 A machine owns the **domain** lifecycle of what it holds once it exists (draft →
-submitted → approved, in the brief's case). It should generally *not* also own the
+submitted → approved, in the brief's case). It should generally _not_ also own the
 **fetch** lifecycle (loading/failed) for the initial GET that produces it — that's a
 generic concern `RemoteData` already models once, consistently, across the app (see
 [Foundations/RemoteData & Async](?path=/docs/foundations-remotedata-async--docs)). Where