Resume a paused parallel-dialer session by auto-fetching next batch

Resume a PAUSED parallel-dialer session.

The voice service's PATCH /sessions/{id}/status rejects ACTIVE - the real resume flow is to call start-session again with the existing session_id and a fresh batch of contacts. This route does the lookup + filtering + forwarding in one shot so an MCP caller only has to supply the session id (and optionally a batch size).

Steps performed server-side:

1. Fetch the session via GET /api/parallel-calls/sessions (filtered to the caller's org). Voice has no per-id GET, so we page with page_size=200 and find the row.
2. Verify the session belongs to the caller's org and is in the PAUSED state. ACTIVE / COMPLETED sessions return 422.
3. Read list_id and the list_offset cursor from session_metadata. Sessions created without a list_id (ad-hoc / campaign-mode) cannot be resumed via this route and return 422.
4. Page contacts out of the source list starting at the cursor, skipping rows already in session.contact_ids and rows that have no usable phone field.
5. Forward up to max_contacts rows to voice's /api/parallel-calls/start-session with the existing session_id. Voice de-duplicates active calls within the session and auto-promotes status to ACTIVE on success.

The list_offset we send back to voice is advanced by the total number of rows we read from the list (called + skipped + dialed) so a future resume picks up where we left off, not where the previous pause cursor sat.