Runner selection: pool size, failure classification and payment_sent on rejections #70

The builder engine (proposal) will build its runner failover on runner_selector / RunnerSelectionCursor. Three things are missing for that.

Today (main at 44df061):

• RunnerSelectionCursor.next tries candidates in discovery order and moves on after any exception.
• Its candidates come from discover_orchestrator_runners, which returns the runners of the first batch of five orchestrators that has any.
• There is no setting for how many candidates to consider, no ordering hook, and no way to tell a capacity refusal from other failures.
• RunnerRejection records only the URL and a reason string, so a caller cannot tell whether a failed attempt had already paid. With a session prepay, a start refused on capacity has paid.

Request:

1. A maximum pool size, so selection can consider runners across more than one orchestrator batch.
2. An ordering hook, or ranking inputs.
3. A classified failure reason: capacity refusal versus unreachable versus other.
4. Whether payment was sent, on each rejection.

Related: #37 forwarded orchestrators through reserve_session. That change is on main, but #36 is still open.