fix(security): keep ALLOW_LOCAL_AI_PRIVATE_HOSTS=true for the operator's own AI, deprecated

Making `=true` grant nothing would stop a single-user self-host's local
model on a patch update. It is deprecated for one release cycle instead,
in a narrowed and safe form: it still grants a private host, but only to
the operator's own configurations (the instance-wide admin provider and
AI settings saved on an admin account), and only through the pinned
operator-approved dispatcher, so redirects stay forbidden and metadata,
link-local and unspecified addresses stay refused. A non-admin account's
own base URL needs an exact origin in AI_PRIVATE_ORIGINS.

Provider resolution passes the owning account's role to the client
(`operatorTrusted`); the save route and the connection test apply the
same rule to the account being configured. The boot summary now says the
setting is deprecated and names the replacement, and the admin AI
settings page shows the exact AI_PRIVATE_ORIGINS line for the private
origins saved on the instance (every account's Local and gateway URL and
the admin base URL, scheme, host and port only), so the operator can copy
it and drop the old setting.

.env.example

@@ -116,7 +116,8 @@ API_TOKEN_HMAC_KEY="REPLACE-WITH-OUTPUT-OF-openssl-rand-hex-32"
 # addresses stay refused even when listed. See docs/integrations/ai-providers.md.
 # AI_PRIVATE_ORIGINS=""
 # Older form, kept for existing installs: an exact host list still works
-# (e.g. "ollama.lan,10.0.0.5"). "true" no longer opens every private host.
+# (e.g. "ollama.lan,10.0.0.5"). "true" is deprecated: it now covers only the
+# admin AI key and admin accounts' own AI settings, and will be removed.
 # ALLOW_LOCAL_AI_PRIVATE_HOSTS=""
 
 # Daily-briefing output-token ceiling (optional). Default 2500, clamped to