chore: regenerate for the forecast verification halt [HOLD — needs robosystems#1109]

[jfrench9]

⚠️ Do not merge before robosystems#1109

This was regenerated against a local stack carrying that branch, not against origin/main. The server does not return halted_at yet and does not halt. Merging and publishing first would ship a client documenting behaviour the deployed API doesn't have — including a description telling integrators that false halts the walk, when the deployed server never halts.

Additive, so no version concern — purely an ordering one.

What

ComputeForecastResponse.halted_at — the month where the forecast walk stopped because verification failed, or null if it ran the full horizon.

Each month's opening balances are the previous month's closing balances, so computing past a failure doesn't yield merely unverified months — it yields months derived from a known-wrong one. The walk now stops and names where, and months_computed ends there.

ForecastMonthLite.verification_passed — same type, honest description. It is tri-state and the third state is not the first:

Value	Meaning
true	rules ran, all passed
false	something failed — halts the walk
null	no rules ran — unverified, not verified

Consumers had been treating null and true alike, which meant a rule corpus that silently stopped binding would have looked like a passing forecast.

Gate

519 passed, 17 skipped. ruff check + ruff format --check + basedpyright clean.