feat(deps): next-intl scaffold (English-only, future locale-add ready)

Minimal next-intl wire-up so future i18n additions are a config
change, not a code rewrite. No URL routing changes — there's no
`/<locale>/` prefix because there's no second locale today.

- `src/i18n/request.ts` — request-scoped locale + messages loader,
  hard-coded to 'en'
- `messages/en.json` — common namespace with a few sample keys
- `next.config.ts` — withNextIntlPlugin wraps the config
- `src/app/layout.tsx` — wraps body with NextIntlClientProvider so
  client components can `useTranslations('common')` now

When a real locale target appears (Polish for marina users, Italian
for broker portal, etc.):
1. Add `messages/<locale>.json`
2. Move route folders under `app/[locale]/` to enable URL routing
3. Add a `routing.ts` with the locale list + default

Verified: tsc clean, vitest 1315/1315, next build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/i18n/request.ts

@@ -0,0 +1,20 @@
+import { getRequestConfig } from 'next-intl/server';
+
+/**
+ * next-intl request configuration (server-side).
+ *
+ * We're shipping the framework without routing — there's no `/<locale>/`
+ * URL prefix yet because there's no localisation target (English-only
+ * today). When/if we add a second locale, swap to next-intl's "i18n
+ * routing" mode and move route folders under `[locale]/`.
+ *
+ * The plugin in `next.config.ts` points at this file. Components call
+ * `useTranslations('common')` to opt in.
+ */
+export default getRequestConfig(async () => {
+  const locale = 'en';
+  return {
+    locale,
+    messages: (await import(`../../messages/${locale}.json`)).default,
+  };
+});