fix(backend): REST schedule listing scans the whole jobstore to show paused schedules

Listing schedules over REST now scans the whole jobstore, because showing a paused schedule needs include_paused=True and that routes through the unfiltered path.

list_graph_execution_schedules and list_all_graphs_execution_schedules (backend/api/features/schedules/routes.py:100-130) pass include_paused=True so that a paused schedule appears in the UI at all — the point of #14416. That flag takes Scheduler._get_jobs_cached(), the unfiltered apscheduler_jobs scan whose own docstring names it as the Sentry slow query, rather than the SQL-filtered _get_active_jobs_cached(). A 5-second TTL cache bounds it, so the cost is one multi-second read per window rather than per request — but that read now sits in front of a user-facing listing, and it grows with schedule history rather than with what the user has.

The fix is to stop asking for everything: fetch the active set through the SQL-filtered path, query only the paused rows that have to be surfaced, and union them. "The paused rows that have to be surfaced" is a small set by construction — hidden_expert_ids already drops the ones belonging to archived experts — so the second query can be narrow.

A test that would prove it: assert the listing handler does not call _get_jobs_cached, with a paused schedule still present in the result.

Found by the autoreviewer on #14416 (approved, 0 blockers); not fixed there, because it is a change to the scheduler's query surface rather than to that PR's diff.