Mpc Tick

Run one MPC pass: discover → score → assign → lead.

CHUNKED (max_postings set — what mpc-cron.yml sends): the first call (no cursor) runs the discovery stages and returns next_cursor; each following call passes that cursor back and matches up to max_postings postings inside a time budget, until remaining is 0. Each call fits well inside Railway's 5-minute request limit, which the single call blew on 7 of 8 runs Sep 23 - Oct 1. See the matcher's run_tick docstring. Without max_postings this is the old single call, unchanged.

Driven by .github/workflows/mpc-cron.yml (external, weekdays). Never an in-process scheduler — an interval trigger inside crm-api starves on ephemeral Railway replicas, which is what silently froze enrollment for two days in August while every gate read healthy.

AUTHED with X-Cron-Token, unlike /enroll-tick above. An earlier version copied that endpoint's no-auth justification, which was wrong: /enroll-tick takes NO PARAMETERS and drains a pre-existing queue, buying nothing. This one takes limit, which feeds cap = limit or daily_send_cap() and therefore overrides MPC_DAILY_SEND_CAP entirely, and it spends TheirStack, Hunter and Anthropic credits on every call. An anonymous POST could have drained the monthly TheirStack plan in ~50 requests. limit is now bounded as well; two guards, because the blast radius is the shared ruzora.com sending domain that every outbound channel rides on.

dry_run=true returns the plan without creating leads or writing the ledger — the batch-approval surface.

NOTE: this creates leads. It does not send. The existing enrollment tick picks them up and resolves instantly_campaign_mpc; with that flag unset, nothing goes out.