fix(SUB-003): subscription rate-limit — persist reset time, skip retries on 429, default max_retries=0 (#476)

[vybe]

Summary

• Persist rate_limited_until — parse "resets 8pm (America/New_York)" from the 429 body and store in a new subscription_credentials.rate_limited_until column. is_subscription_rate_limited() checks this authoritative timestamp before falling back to the 2h event-count heuristic, preventing the slow ping-pong where Trinity considers an exhausted subscription viable again every 2 hours while Anthropic's actual window is 5–8h.
• Never retry rate-limited executions — _maybe_schedule_retry() now returns early on 429/rate-limit errors. The next cron tick is the correct recovery path; queuing retries during a subscription outage just floods the backlog with guaranteed-to-fail work.
• Default max_retries from 1 → 0 — retries are now opt-in per schedule. Scheduled agents are typically stateful and idempotent; skipping a run is preferable to thundering-herd replay when many tasks fail simultaneously.

Changes

• db/migrations.py — add _migrate_subscription_rate_limited_until (ALTER TABLE adds column, idempotent)
• db/subscriptions.py — set_subscription_rate_limited_until() setter + updated is_subscription_rate_limited() checks durable timestamp first
• database.py — expose new setter on facade
• services/subscription_auto_switch.py — _parse_rate_limit_reset() parser + wired into handle_rate_limit_error()
• db_models.py + scheduler/models.py + db/schedules.py — max_retries default 1 → 0
• scheduler/service.py — early return in _maybe_schedule_retry() for rate-limit errors

Test Plan

• Existing subscription tests pass
• is_subscription_rate_limited() returns True when rate_limited_until is in the future
• is_subscription_rate_limited() clears expired rate_limited_until and falls back to event count
• _parse_rate_limit_reset("resets 8pm (America/New_York)") returns a future UTC ISO string
• _maybe_schedule_retry() returns without scheduling when error contains "429"
• New schedules default to max_retries=0

Closes #476

🤖 Generated with Claude Code

[vybe]

Hey @vybe — this PR is targeting main directly. Per our dev workflow, all feature/fix branches should target dev instead (feature/* → dev → main). Could you rebase onto dev and update the base branch? Thanks!