perf: friends list reads in-match and live lineup state from the active matches

[lukepolo]

The friends subscription is the biggest database cost on both 5stack.gg and cs.playhard.gg. For every friend, on every refresh, it walked that friend's entire match history twice: once in is_in_another_match, and once in the player_lineup(where: lineup.match.status = Live) filter.

• is_in_another_match now starts from the panel's active matches and probes the friend's lineup on both columns of its unique key, so the cached generic plan can't fall back to the steam_id index and the friend's history. The answers are unchanged.
• New partial index idx_matches_active_schedule (status, scheduled_at) serves the active statuses and the near-term Scheduled matches as two index ranges, so matches scheduled further out are never read.
• Drops idx_match_lineup_players_steam_id. The planner prices it exactly like the unique key for a (match_lineup_id, steam_id) probe and breaks the tie by index age, so a REINDEX of it brought the whole-history plan back (1,008 extra buffers). idx_match_lineup_players_steam_id_lineup_id already serves every steam_id lookup; the friends subscription reads the same 9,075 buffers without it.
• New players.live_lineup computed field (get_player_live_lineup) returns only lineup rows in Live, non-practice matches. The web keeps the same where/limit on it, so Hasura's checks run on at most one row.
• Measured on the exact subscription SQL from Hasura v2.50.3, 90 friends, prepared like Hasura. The panel also has 6,000 one-off import matches and 200 matches a week out. The response is identical:
  • ~37 matches per friend: 23.7ms / 40,393 buffers → 15.8ms / 9,075
  • ~160 matches per friend: 56.8ms / 157,069 buffers → 15.5ms / 9,075
• test/friends-live-state.spec.ts covers:
  • is_in_another_match by status, by lineup and with paused tournaments (these pass on main too)
  • live_lineup against the permission-filtered match join, including practice sessions
  • cost guards (generic plan): a 150-match veteran, history spread among one-off players (all indexes rebuilt first), and 400 extra finished / far-off matches on the panel
  • a catalog guard against a steam_id-only index
  • Main fails 7 of these; earlier commits on this PR fail the practice, spread-history, far-off Scheduled and index guards.
• The web moves to live_lineup in web#858, which needs codegen after this deploys. player_lineup keeps working until then.