fix(custom-model): don't clamp DEEPSEEK_API_KEY as a privileged env key

CI caught a real regression: DEEPSEEK_API_KEY was added to deepseek's
privilegedEnvKeys alongside DEEPSEEK_BASE_URL on the theory that "the pair
travels together," but that contradicts the documented and tested design
(clampEnvOverridesForOwner()'s own docstring in session-routes.ts) — a
non-granted owner supplying their OWN DeepSeek key removes privilege
rather than granting it, since the exfiltration vector is the BASE URL
(which redirects the server's own forwarded key to a foreign host), not
the key itself. Removed it from the list; test/deepseek-mode.test.ts's
existing two clamp tests now pass again.

Also swapped that test's "unrelated override" example off CODEX_HOME,
which the earlier commit in this same PR legitimately made privileged
(closing a real pre-existing gap, documented in PR.md) — so it stopped
being a valid "unrelated" example the moment that fix landed.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017HqNWfmtBU2KN29SvSVWB3

test/deepseek-mode.test.ts

@@ -372,7 +372,10 @@ describe('DeepSeek multi-user clamp: the env-var half', () => {
   });
 
   it('leaves unrelated overrides alone, and returns the same object when there is nothing to strip', async () => {
-    const input = { DEEPSEEK_API_KEY: 'sk-test', CODEX_HOME: '/tmp/cx' };
+    // CODEX_HOME is a poor "unrelated" example here — it is itself a privileged key
+    // (codex's own registry entry), so a genuinely non-privileged one is needed to
+    // prove the identity-return fast path, not just that DEEPSEEK_API_KEY is exempt.
+    const input = { DEEPSEEK_API_KEY: 'sk-test', OPENCODE_LOG_LEVEL: 'debug' };
     const out = await _clampEnvOverridesForOwner('nobody', input);
     expect(out).toBe(input);
     expect(await _clampEnvOverridesForOwner('nobody', undefined)).toBeUndefined();