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>

next.config.ts

@@ -1,7 +1,13 @@
 import type { NextConfig } from 'next';
 import bundleAnalyzer from '@next/bundle-analyzer';
+import createNextIntlPlugin from 'next-intl/plugin';
 import { withSentryConfig } from '@sentry/nextjs';
 
+// next-intl plugin — points at our request-config entrypoint. Even
+// though we ship only English today, the plugin is wired so future
+// locale additions are a config-only change, not a code rewrite.
+const withNextIntl = createNextIntlPlugin('./src/i18n/request.ts');
+
 const isProd = process.env.NODE_ENV === 'production';
 
 // Wrap the config with the bundle analyzer. Run `ANALYZE=true pnpm build`
@@ -135,4 +141,4 @@ const withSentry = process.env.NEXT_PUBLIC_SENTRY_DSN
       })
   : (cfg: NextConfig) => cfg;
 
-export default withSentry(withBundleAnalyzer(nextConfig));
+export default withSentry(withBundleAnalyzer(withNextIntl(nextConfig)));