fix(cortex): let the orchestrator wait out a lost claim broadcast master
Callosum is a best-effort broadcast bus. When a burst of logs.line traffic caused the server to evict a slow consumer, cortex talent requests broadcast in that window were simply lost. cortex_request's claim wait was a fixed 3 sends about 1.0s apart, so a lost request exhausted the schedule in ~3s and raised CortexNotClaimed. For the think orchestrator that became talent.fail state=request_lost and the unit failed, to be re-walked hours later: 83 such failures over 24h on a single-GPU local-model install, 67 of them on sense. A delivered request claims in milliseconds, so the schedule exists to survive a lost broadcast, not a slow one. Make it a per-call choice. cortex_request gains a keyword-only claim_windows, where len(windows) is the total send count including the initial broadcast and element i is the poll window after send i. The default (1.0, 1.0, 1.0) reproduces today's ~3s fast-fail exactly, so interactive callers -- convey chat, tools/sol, engage -- keep their latency and take no diff. _dispatch_cortex_request, which fronts all seven thinking.py spawn sites, opts into PATIENT_CLAIM_WINDOWS (1, 2, 4, 8, 15; ~30s budget). Replace _CLAIM_WINDOW_S and _CLAIM_MAX_BROADCASTS with the two schedules; the window walk makes the send count structurally equal to len(windows) rather than implied by a max-broadcasts counter. Resolve the default at call time so tests can monkeypatch it. Widen the 49 cortex_request test mocks to accept the new keyword. The mocks intercept think.cortex_request, so they must tolerate what the wrapper passes; the alternative -- swallowing unknown kwargs in production -- would be a compat shim. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>