feat!: make a short fit an error and raise the default iteration cap

`ITERATIONS` was 30, and overrunning it returned `Ok` with
`converged: false`. Both halves were wrong.

The cap is a runaway guard, not a budget: the sweep exits as soon as the
step falls below `epsilon`, so a high cap costs nothing on a history that
converges. Measured on one needing four sweeps, `max_iter` 30 and
100_000 both finish in 4 iterations and ~130us. So 30 could never make
anything faster — it could only stop a healthy history early, and it did:
160 events over 100 competitors already needs 42.

Not scaled to the history, because iteration count tracks how loopy the
graph is rather than how big it is. At a fixed 320 events over 40 slices,
varying only the competitors sharing them: 3 competitors needs 2_789
sweeps, 10 needs 1_068, 100 needs 90, 400 needs 2. Three orders of
magnitude on identical event and slice counts, so any formula in those
two numbers would be badly wrong on some real shape. A single value set
high enough that reaching it means oscillation is the honest version.

With the cap raised, stopping at it means something is genuinely wrong,
so `converge` now returns `InferenceError::NotConverged` rather than a
flag on a success. A short fit is wrong by a little — every rating
finite, the ordering sensible, nothing saying the numbers were still
moving — and a flag has to be checked while `let _ = h.converge()` is the
natural way not to. That is not hypothetical: it is how a real defect hid
in this crate's own test suite.

`converge_partial` returns the short fit for callers who want one. Only a
single existing test needed it, which is the evidence that a capped fit
is a deliberate choice rather than the common case.

Also corrects the `ITERATIONS` docs, which claimed convergence cost is
"roughly linear in the cap". It is linear in the iterations actually run.

BREAKING CHANGE: `History::converge` returns `Err(NotConverged)` where it
previously returned `Ok` with `converged: false`. Callers that want the
old behaviour should use `History::converge_partial`. The default
`max_iter` changes from 30 to 10_000, so a history that was silently
truncated will now converge properly and its numbers will move.

Closes #50

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011hcFjNDmHXZF8URGLku5zZ

src/lib.rs

@@ -158,22 +158,43 @@ pub const P_DRAW: f64 = 0.0;
 pub const EPSILON: f64 = 1e-6;
 /// Default cap on convergence sweeps.
 ///
-/// **This is a floor, not a recommendation.** It is adequate for small
-/// histories and is quickly outgrown: a history of 400 events over 100
-/// competitors already stops here with a final step of ~7e-3 against the 1e-6
-/// default tolerance — four orders of magnitude short — and a dense joint model
-/// of ~2,000 nodes over ~3,300 events has been measured needing 76 to 161.
+/// **A runaway guard, not a budget.** The sweep exits as soon as the step falls
+/// below `epsilon`, so the cap is never reached by a history that converges and
+/// raising it costs nothing. Measured on a history that needs four sweeps:
 ///
-/// Overrunning it is not an error, and deliberately so: `converge` returns a
-/// [`ConvergenceReport`] whose `converged` flag says what happened. But a fit
-/// that stopped short is *wrong by a little*, which is the worst available
-/// failure — every rating is finite and ordered sensibly, and nothing in the
-/// numbers themselves says they were still moving. Read the report; the type is
-/// `#[must_use]` for that reason.
+/// ```text
+/// max_iter      30: 4 iterations, 129.9 us
+/// max_iter 100_000: 4 iterations, 131.9 us
+/// ```
 ///
-/// Raise it via [`ConvergenceOptions`]. Convergence cost is roughly linear in
-/// the cap, and for anything but a toy the extra sweeps are milliseconds.
-pub const ITERATIONS: usize = 30;
+/// This was `30` until it was measured, and 30 truncated ordinary healthy
+/// histories: 160 events over 100 competitors already needs 42. Because a short
+/// fit is finite and sensibly ordered, that was invisible.
+///
+/// # Why it is not scaled to the history
+///
+/// The obvious improvement — pick the cap from the node or event count — does
+/// not work, because iteration count is driven by how *loopy* the graph is
+/// rather than how big it is. At a fixed 320 events over 40 slices, varying
+/// only the number of competitors sharing them:
+///
+/// ```text
+/// competitors    appearances each    iterations
+///           3                 213         2_789
+///          10                  64         1_068
+///          50                12.8           206
+///         100                 6.4            90
+///         400                 1.6             2
+/// ```
+///
+/// Three orders of magnitude apart on identical event and slice counts. Any
+/// formula in those two numbers would be badly wrong on some real shape, so the
+/// cap is a single value set high enough that reaching it means the fit is
+/// oscillating rather than merely large.
+///
+/// Reaching it is [`InferenceError::NotConverged`]. See
+/// [`History::converge`](crate::History::converge).
+pub const ITERATIONS: usize = 10_000;
 
 /// Largest team count `History::predict_outcome` will enumerate.
 ///