feat(web): expose provider auth status

[testikun]

Problem

The Web configuration work tracked by #348 can list currently available models, but cannot explain which Pi providers exist, which authentication methods they support, or whether Pi currently considers them configured. Credential material must not cross the Web protocol boundary.

Value

Users and support tooling get actionable provider availability without exposing API keys, OAuth tokens, configured command values, or credential labels.

Approach

• Read provider definitions and AuthStatus only from the active Pi ModelRuntime.
• Project exact bounded provider ids, bounded names, supported api_key/oauth methods, configured state, subscription state, and a strict non-secret source-category allowlist.
• Cap scanning and response item counts and report omitted or truncated entries explicitly.
• Expose the projection through authenticated GET /api/providers/auth-status.
• Keep the runtime-controller seam optional so existing embedders fail explicitly rather than fabricating status.

This is distinct from #367 runtime diagnostics and #375 thinking-state inspection. Login/logout writes and UI remain follow-ups.

Validation

• bun run check
• bun run test: 1242 passed, 0 failed, 1 skipped; Vitest 30 passed
• focused Pi runtime and Web Host tests: 40 passed
• secret regression injects fake API key, OAuth token, and credential label values and proves none serialize
• git diff --check

Impact

• User-visible behavior: authenticated API consumers can inspect provider auth availability; no UI changes.
• Model-visible context/tools: none.
• Runtime/lifecycle: synchronous read-only projection from Pi ModelRuntime.
• Persisted config/data: none.
• Compatibility/risk: additive optional controller method and endpoint; no credential reads or writes are introduced.

Related to #348.

[testikun]

CI context: both Linux Node jobs reach the pre-existing packed standalone Web CLI smoke, install the tarball, and then the server exits before announcing its origin (kill: No such process). Windows and the other checks pass. This matches the independently reproduced fresh-install peer-dependency failure tracked in #328, where npm selects Pi 0.85.0 and @earendil-works/pi-server cannot be resolved. Evidence: #328 (comment)

This PR does not change package metadata, CLI startup, or peer-dependency resolution. Its local check, focused tests, full Node suite, and Vitest suite pass as recorded in the PR body.