fix(config): handle 'local-agent' provider in getLLMConfig

[hoptoad-off]

What & why

Routing a mission through a connected local CLI agent (Claude Code / Codex /
Hermes) sets the LLM provider to local-agent. But getLLMConfig's switch
in src/config/index.ts had no case 'local-agent', so it fell through to
default and threw Unknown provider: local-agent — aborting every keyless
mission with a REFUSED, even though local-agent is a registered provider
wired to LocalAgentAdapter everywhere else in the codebase.

Repro: connect a local agent in the War Room (no API key), launch a mission →
Backend error: Unknown provider: local-agent.

Fix

Add a case 'local-agent' mirroring codex: keyless (no apiKey/baseUrl),
with the connected agent id (codex|claude|hermes) carried in model and a
sensible default.

Verification

• getLLMConfig('local-agent','claude') now resolves to
  {provider:'local-agent', model:'claude'} instead of throwing.
• npx tsc --noEmit clean; src/__tests__/provider-models.test.ts 15/15 pass.
• End to end: a keyless mission now advances into the reconnaissance phase and
  the recon engine produces real tool-backed findings.

[hoptoad-off]

Triage note: this is backend-only (src/config/index.ts) and independent of the UI syntax fixes — the War Room docs/index.html breakage is already handled by #112 (my duplicate UI PR #117 is now closed in favor of it).

This PR only fixes getLLMConfig throwing Unknown provider: local-agent, which aborts every keyless (connected-agent) mission with a REFUSED before recon can start. The other two switch blocks (setDefaultProvider/setDefaultModel) have no throwing default, so this single added case is sufficient. Verified end-to-end: a keyless mission now advances into reconnaissance and the recon engine produces real tool-backed findings.

[jmagly]

Reviewed PR #118 at 2f081b668b8594516e18ef4a0ff97dc43e0f5dc2.

The implementation is small and locally behaves correctly, but the changed failure branch has no regression test. Existing provider and local-agent tests do not call config.getLLMConfig with local-agent, so removing this case would leave CI green and restore the keyless-mission failure.

Please add focused assertions that:

• local-agent with model claude returns provider/model without API key or base URL
• omitting the model uses the intended default

Verification:

• npm run typecheck: pass
• targeted provider/local-agent tests: 37/37 pass, but do not cover this branch
• npm test: 644/644 pass
• No GitHub checks reported on this head
• Public-input threat preflight: low risk

[hoptoad-off]

Thanks @jmagly — added the regression coverage in ce92f93 (src/__tests__/local-agent-provider.test.ts, following the deepseek/venice provider-test style):

• local-agent + model claude → provider/model set, no apiKey/baseUrl
• any supported agent id (codex|claude|hermes) passed as model is preserved
• omitting the model falls back to the default agent id
• getLLMConfig('local-agent') does not throw (the exact case that was broken)
• AVAILABLE_MODELS['local-agent'] surfaces the connected-agent ids

Verification here: new file 5/5 pass, tsc --noEmit clean, provider suites green.

Note (unrelated to this change): local-agent-path-resolution.test.ts (#78) shows 3 failures on my box, but they reproduce identically on the base commit 2f081b6 and are caused by a real claude binary on PATH (/usr/bin/claude) interfering with the well-known-dir detection mock — not introduced by this PR, and green on a clean env.