Redesign bisection events, separate init from loop, extract shared types

[dyreby]

What

Bisection's event types wrapped &EvaluateResult, a private intermediate type that made events unconstructable in tests without driving the full solver. This blocked focused unit testing of observer logic and was the only solver with this limitation — golden section's events were already directly constructable.

This PR redesigns bisection's events to match the golden section pattern, separates endpoint initialization from the midpoint loop, and extracts shared bracketing types to the equation module level in preparation for ITP (#269).

Closes #250.

How

Event redesign — Replace the three phase-based variants (Left/Right/Midpoint, each carrying &EvaluateResult) with three outcome-based variants (Evaluated/ModelFailed/ProblemFailed) carrying plain public fields. Every event carries a &Bracket reference since events are only emitted during the midpoint loop.

Init/loop separation — Endpoint evaluation moves out of the observer protocol entirely, matching golden section's architecture. Two entry points:

• solve takes [f64; 2], evaluates endpoints, builds a bracket, and runs the midpoint loop. Convenient for most callers. Endpoint failures are hard errors. Endpoints are automatically ordered.
• solve_from_bracket takes a pre-validated Bracket and runs the midpoint loop directly. Use this when you need control over endpoint evaluation — e.g., domain-specific error recovery, noise filtering near bracket boundaries, or skipping redundant evaluations.

Bracket::new — Now public. Takes (f64, Sign) pairs for left and right. Left must be strictly less than right (no silent reordering). Signs pair structurally with their endpoints.

Shared type extraction — Bracket, Sign, Bounds, BracketError, Best, Solution, and Status move from bisection to the equation module. These are identical across bracketing root finders and will be reused by ITP. Bisection re-exports them to preserve its public API surface.

New types:

• Point { x, residual } — equation analog to golden section's Point { x, objective }
• BracketError::Inverted — for left > right

Migration

Previously, observers received Left/Right/Midpoint events and could recover from endpoint failures via AssumeResidualSign. Observers now only see midpoint events.

If your observer handled endpoint failures, evaluate endpoints yourself and use solve_from_bracket:

// Before: observer recovered from endpoint failures
let solution = bisection::solve(&model, &problem, [a, b], &config, observer)?;

// After: evaluate endpoints, build bracket, then solve
let left = equation::evaluate(&model, &problem, [a])?;
let right = equation::evaluate(&model, &problem, [b])?;
let bracket = Bracket::new(
    (a, Sign::of(left.residuals[0])),
    (b, Sign::of(right.residuals[0])),
)?;
let solution = bisection::solve_from_bracket(&model, &problem, bracket, &config, observer)?;

Testing

Observer tests in twine-observers now construct bisection events directly without driving the solver, matching the golden section test pattern.

[gdtroszak]

Looks good. Clean separation between the two commits, and the event redesign delivers on #250's acceptance criteria. Two minor comments inline.

[gdtroszak]

Consider moving this to EvalContext or a free function in the eval_context module. Event is otherwise a pure data type (variants + accessors), and emit_failure adds observer dispatch responsibility. Not blocking — it works — but it couples event construction with observer coordination in a way that might feel odd as more methods land here.

[dyreby]

Good call — moved to EvalContext::observe_failure, Event is back to pure data. Doc nit addressed too. 7112098

[gdtroszak]

Nit: might be worth mentioning the specific error variants returned for endpoint failures (Error::Model / Error::Problem) since the doc emphasizes that endpoint failures are now hard errors.