fix(security): never vend the LLM API key to the browser

[NovakPAai]

Summary

A server-side audit found that GET /api/llm-config returned the stored LLM API key (Settings → Integrations → AI titles) verbatim on every Settings load — unmasked in each network response and devtools log, then pre-filled into the password input's value. The GitHub endpoints already follow the right rule (/api/github/profile explicitly strips token/repoToken with a "Never vend raw tokens to the browser" comment); the LLM endpoint was the one exception.

• GET /api/llm-config now returns { model, url, hasKey, keyHint } — keyHint is a ••••-masked last-4 so the user can tell which key is stored without the secret ever reaching the DOM.
• Because the key no longer round-trips, POST with an empty apiKey field means "keep the stored key" (otherwise every URL/model tweak would silently wipe it); an explicit { clearApiKey: true } removes it.
• saveLLMConfig writes ~/.claude/codedash-llm.json with mode 0600 and chmods a pre-existing world-readable file from older versions (matching the 0600 convention the workspace-layouts/commands stores already use).
• Frontend shows the stored-key state via the input placeholder (••••1234 (saved — type to replace)), never pre-fills the value; autocomplete="new-password" keeps browser autofill managers out. saveLLMSettings also surfaces save failures now instead of toasting "saved" unconditionally.
• Drive-by in the same security bucket: rel="noopener noreferrer" on all target="_blank" links in leaderboard.js (reverse-tabnabbing).

Test plan

• node --test "test/**/*.test.js" — 262 passed, 1 skipped (win32-only); includes 5 new source-contract tests (test/llm-config-redaction.test.js)
• Live round-trip against a running server: GET carries no apiKey field and shows ••••1234; config file lands -rw-------; a save with an empty key field preserves the stored key; clearApiKey: true clears it (original local config backed up and restored after the test)

🤖 Generated with Claude Code