v0.2.4 - redis-unavailability hardening

Fixes two bugs that affect anyone running v0.2.3 or earlier, both of which surface at event
time when Redis becomes unavailable. No migration and no config change on upgrade.

• The API-token rate limiter failed OPEN when Redis was unavailable: a Redis blip silently
  removed the per-token throttle entirely — the credential built for automation losing its
  limit exactly when the platform is already stressed — while login/register/submit failed
  closed as a bare 500. Now all four (login, register, submit, token) fail closed with 503 +
  Retry-After, and the condition is logged and counted distinctly
  (osctf_ratelimiter_unavailable_total) so "Redis is down" reads differently from "you're
  being throttled". Pinned by handlers.TestLimitFailsClosedWhenLimiterUnavailable.

• The scoreboard went dark (500) when Redis was unavailable instead of degrading. A live read
  now degrades to a bounded, counted Postgres recompute
  (osctf_scoreboard_degraded_served_total) — a slightly slower board, not no board — while a
  frozen read stays fail-closed, because a frozen snapshot lives only in Redis and has no
  Postgres authority to fall back to (the two paths behave differently under the same outage,
  on purpose). Pinned by
  scoreboard.TestScoreboardRedisOutageDegradesButFreezeFailsClosedIntegration.

Both fixes backport cleanly from the v0.3 line (they touch code unchanged since v0.2.3).

Operator action on upgrade: none. No database-schema or OpenAPI change; the fixes are
behavioural. New metrics: osctf_ratelimiter_unavailable_total (limiter failing closed, by
scope) and osctf_scoreboard_degraded_served_total (board recomputed from Postgres during a
Redis outage).