wishlist: bound what a single path may cost (no mechanism today to stop a long-running path)

[ofloveandhate]

Wishlist: a way to bound what a single path may cost

There is currently no mechanism to stop a path that is taking too long. The only budget a
tracker carries is SteppingConfig::max_num_steps (default 1e5, → SuccessCode::MaxNumStepsTaken),
and a step count is a poor proxy for cost: a step at 90 digits costs orders of magnitude more
than one at 16, so the same budget bounds wildly different amounts of work depending on where
adaptive precision took the path.

Field evidence

From a cellular-decomposition consumer, in a comment written to explain why a correctness
improvement had to be left off by default:

moving a fiber endpoint onto its exact tangency makes that boundary curve's interslice
tracking explode (measured: seed 204, one boundary curve 2s → 130s+; not RNG, not
spurious)

A single path costing 130 seconds is bad on its own, but the second-order effect is worse:
because there is no way to bound it, a correct refinement had to be disabled to keep runs
finishing. An unbounded path cost turns "this makes the geometry right" into "this makes the
run unusable", and the correctness work loses.

That is the shape of the request — not "make paths faster", but "let a caller say how much a
path is allowed to cost, and get an honest failure code when it exceeds that."

What would help

A per-path budget that a caller can set and that produces an ordinary non-success code
(SuccessCode:: — a new one, or a reuse), so the existing retry/rescue machinery treats it
like any other honest failure rather than a hang.

Please prefer a WORK budget over wall-clock. Wall-clock makes a run non-reproducible: the
same recorded solve would truncate on a loaded machine and complete on an idle one, so a
replay would not reproduce the original. That directly undercuts the records contract
(b2rec/1, ensure-answered recall, ADR-0042..0047) — what got computed should not depend on
machine load. A deterministic budget truncates in the same place every time.

Candidate work measures, roughly in order of how well they track real cost:

1. precision-weighted steps — e.g. accumulate steps × digits (or digits²), which
   bounds actual arithmetic rather than iteration count;
2. a step budget that is actually consulted per-path by callers — max_num_steps exists
   but at 1e5 it is effectively no bound; the useful thing may be documentation plus a
   sane default, since a consumer already lowers it to 2000 for rescue passes;
3. wall-clock, but only as an opt-in safety valve on top of a work budget, clearly marked
   as making runs non-reproducible.

Diagnosing which one bites

SolutionMetaData already reports path_time_seconds, max_precision_used,
precision_changed and time_of_first_prec_increase per path, so it is already possible to
tell whether a slow path is many steps or expensive ones. If a 130s path shows
max_precision_used at 90+, the cost driver is precision escalation rather than step count,
and a plain step cap would not have helped — which is the main argument for a
precision-weighted budget over a step count.

Version: 3.5.0.dev0 (develop @ 8f0cd0f).