v4.10.2

A patch release fixing two defects that left a freshly installed application
unable to hydrate. Both were found by running a real end-to-end MySQL
installation against the published 4.10.1 packages.

Bug Fixes

• @byline/cli — a fresh installation loaded but never hydrated: no
  client-side JavaScript, and signing in to the admin was impossible. The
  scaffolded vite.config.ts names
  use-sync-external-store/shim and use-sync-external-store/shim/with-selector
  in environments.client.optimizeDeps.include, and Vite resolves those bare
  specifiers from the host application's root. The package is only ever a
  transitive dependency — of @base-ui/react and @tanstack/react-store — so
  pnpm's strict layout left it unresolvable there. Vite could not pre-bundle it,
  its conditional CommonJS re-export was interoped into a default-only facade,
  and the named import in @base-ui/utils' store threw during hydration. It is
  now installed as a direct dependency of the host application.

  This was invisible in development of Byline itself, because the reference
  application in this repository is a workspace, not a clean installation of
  published packages. A contract test now asserts that every package named in
  the canonical config's optimizeDeps.include is one the CLI actually installs.

• @byline/cli — every collection route in the admin failed with
  useTranslation must be used inside <I18nProvider>, even though the provider
  was mounted correctly by the admin layout. @byline/i18n/react is imported
  only from inside node_modules, so Vite never gave it its own optimized entry
  and inlined a copy into whichever chunk reached it first;
  @byline/host-tanstack-start is deliberately not pre-bundled, so the admin
  layout loaded a second copy through the regular module pipeline. The result was
  two React Contexts — the provider wrote to one, useTranslation read the
  other. Naming @byline/i18n/react in optimizeDeps.include makes every
  importer, pre-bundled or not, resolve to a single module instance.

• @byline/cli — byline init reported an already-merged vite.config.ts
  as complete rather than bringing Byline's own settings up to date. The merge
  introduced in 4.10.1 treated any key holding a Byline value as finished,
  without checking that value was current, so an application configured by an
  earlier release would never have received the two fixes above — or any future
  change to those settings. A Byline-owned value that has drifted from the
  canonical configuration is now refreshed on the next run. Keys authored by the
  host application are still never modified, and the original file is still
  preserved under a timestamped backup.

All other @byline/* packages bumped to 4.10.2 in lockstep with no
behavioural changes this cycle.