feat: use private network to call API in SSR

[ThibaudDauce]

Configuration

This is enabled by a single optional environment variable:

• NUXT_API_BASE_PRIVATE_NETWORK — the private-network API base used for server-side
  (SSR / Nitro) requests, e.g. http://udata-api:7000. It maps to the private
  runtimeConfig.apiBasePrivateNetwork key (camelCase → NUXT_-prefixed
  SCREAMING_SNAKE_CASE).

When it is unset (default, including dev and CI), behaviour is unchanged: server-side
requests fall back to NUXT_PUBLIC_API_BASE. Set it only in production to route SSR
traffic through the internal network. The browser is never affected — client-side requests
keep using NUXT_PUBLIC_API_BASE (which is also why this key is private and not exposed to
the client).

Known limitations

Only calls made through the shared $api client (and useAPI, which builds on it) are
routed to the private-network base during SSR. datagouv-components is configured with
customUseFetch: useAPI (see app.vue), so its server-side data.gouv API calls are
covered as well.

Code that creates its own $fetch/ofetch instance instead of using $api/useAPI
is not rewritten and would still hit the public API. Today this is limited to
$chartsApi (ChartConfigurator.vue) and a couple of CSV-export / tabular helpers in
datagouv-components — all triggered by client interaction, so there is no SSR leak in
practice. New server-rendered code should go through $api/useAPI.

Implementation note

The rewrite runs in ofetch's onRequest hook and relies on ofetch applying onRequest
before baseURL (verified with ofetch 1.5.1 / ufo 1.6.3, where withBase leaves
absolute URLs untouched). This ordering is an internal detail of ofetch, not part of its
public contract, so it could change on a major upgrade.

[nicolaskempf57]

Seems great ! Can we test it on demo before merging ?