fix(health): stop gating HTTP status on AI vendor health in strict mode

[catomean]

Summary

• /api/health?strict=1 returned HTTP 503 whenever the LLM chain was reported "down" -- a monitoring/orchestration system alerting or acting on that status code would treat it as a reason to restart the process, but a dead API key or exhausted free-tier budget can't be fixed by a restart. That's a pointless restart loop for a problem restarting can't solve.
• The default (no param) path already always answered 200 based on DB reachability; this removes the strict-mode carve-out that made behavior depend on a query param, so the endpoint's HTTP status now never depends on AI/LLM vendor state, full stop.
• LLM health remains in the response body as an informational field, unconditionally -- callers who want to know can still see it.
• The strict param existed only to drive this 503 gating, so it's removed entirely rather than left as dead branching.
• Updated the guard test in tests/__tests__/lib/llm-health.test.ts that asserted the old strict/readiness split to instead assert the route never gates HTTP status on LLM state and no longer references strict.

Note: this repo had a deliberate, previously-merged design (PR #153, 2026-08-28) splitting liveness (default, always 200) from readiness (?strict=1, 503 on LLM down, "point alerting here"). That design was reasoned and tested, not an oversight -- but per the standing fleet-wide rule (a health endpoint must never let AI/LLM vendor status drive its HTTP status, since nothing wired to it can act on that signal usefully), it's being closed the same way as the other two repos with this pattern. strict=1 was confirmed dormant -- nothing in this repo's deploy/CI/monitoring config currently passes it.

Test plan

• npm run typecheck -- clean
• npm run check:selfhost -- clean
• npm run test -- 274 passed, 2 skipped (including the updated health guard test)
• npm run build -- succeeds
• npx eslint on the two changed files -- clean (full-repo npm run lint is currently broken by an unrelated stray git worktree from a concurrent session under .claude/worktrees/, reproduced on main with this change stashed -- not caused by this PR; CI runs a clean checkout and won't have that worktree)
• CI green

🤖 Generated with Claude Code