fix(chat): return 401 without server env-var API-key fallback

[xcjs]

Closes #80

Summary

• The chat API route no longer reads API keys from the server environment (\OPENAI_API_KEY, \ANTHROPIC_API_KEY, \GEMINI_API_KEY, \GOOGLE_GENERATIVE_AI_API_KEY, \DEEPSEEK_API_KEY\ env fallbacks removed)
• Missing/blank client key returns 401 directing the user to Settings, as before
• Keys now come exclusively from the per-request client payload (client-side Settings)

Scope

\server/api/chat.post.ts\ only — matches issue #80's ## Files.

Done when (from #80)

• no key is ever read from the environment

Verification

• 
  pm run typecheck\ passes (exit 0)
• 
  g 'process\.env' server/api/chat.post.ts\ now shows only the two *_BASE_URL\ fallbacks (URLs, not keys) — env-var key reads are gone

[m-vawter]

Approving. Verified locally: with this branch merged onto the #91 e2e suite, 3/3 pass, and the route now takes the key only from the request (the 401 path is unchanged). Two small things, neither blocking:

1. The new comment cites ADR 0012, but NEXT.md frames this step as ADR 0005 conformance, the server-side provider proxy record. Citing 0005 would point readers at the decision this completes.
2. A follow-up idea: a keyless local endpoint (Ollama through the custom OpenAI-compatible provider) still gets a 401, same as before. With a self-hostable north star, allowing an empty key for the custom provider might be worth an issue.