fix(whip/whep): warn loudly when WHIP_AUTH_KEY is unset

[birme]

Summary

• WHIP/WHEP auth validators previously returned true silently when WHIP_AUTH_KEY was unset, leaving these public, internet-facing WebRTC ingest/egress endpoints fully unauthenticated with no operator-visible signal.
• Now log a single loud SECURITY: ... WARN at plugin registration (startup) in both src/api_whip.ts and src/api_whep.ts when the key is absent, so operators are aware of the open endpoints.
• Chose Option B (warn and continue) over Option A (fail-closed exit): fail-closed would break existing deployments that intentionally run without a key. This mirrors the existing REAUTH_AUTH_KEY warning pattern in server.ts.
• Minimal, focused diff: no change to default runtime behavior beyond the added warning; the auth path itself is untouched.

Test plan

• Tests pass (npm test) — 336 passed, 18 suites; new warning visible in test output
• TypeScript compiles (npm run typecheck) — 0 errors
• Lint clean (npm run lint) — 0 errors (only pre-existing warnings)
• Verified warning fires once at startup when WHIP_AUTH_KEY is unset, and auth still enforces a Bearer token when the key is set

Closes #223

🤖 Generated with Claude Code

[birme]

Code review verdict: LGTM (separate code-reviewer invocation, per the self-authored-PR review path — self-approval is blocked by GitHub, so this marker records the verdict).

Minimal, focused, correct. Adds a one-time SECURITY: startup WARN in src/api_whip.ts and src/api_whep.ts when WHIP_AUTH_KEY is unset, mirroring the existing REAUTH_AUTH_KEY warn-and-continue convention in src/server.ts. Verified: warning fires once at plugin registration (not per-request), both WHIP and WHEP endpoints covered, auth logic unchanged. typecheck / lint / unittests all pass.

Non-blocking follow-ups (not gating): (1) the opts.whipAuthKey?.trim() guard also matches a set-but-whitespace key, where "not set" is slightly misleading — REAUTH's wording distinguishes the two; (2) a small regression test asserting the warning fires would lock in the behavior. Worth a follow-up, does not block merge.