feat(agent,cli): recognize load-timing races as a distinct repair category

[HappyDevs1]

Summary

Stacked on #550 (the base repair loop) — this is PR 3/4.

The repair loop had two moves: rewrite a step's text, or declare it an engine gap. That meant a genuine timing race — the target was right, the page just hadn't settled — burned an attempt guessing new (wrong) text instead of just waiting longer, since there was no way to say "the target is fine, give it more time."

• Adds a third patch option, widen_timeout_seconds, alongside step_yaml/engine_gap.
• widen_timeout applies it via a narrower path than a full step rewrite: it regex-replaces only the within Ns window, capped at 120s, so a timing-race fix can't also change what the step is waiting for.
• AgentError::PreviousStepIncomplete ("the page reports: still loading") now gets its own diagnosis category, page-not-ready-transient, instead of falling into the generic engine-gap bucket, so the prompt can ask the model to distinguish "wrong target" from "right target, not settled yet."

Verified live

Replayed the exact multi-drift scenario that previously exhausted its attempt budget on a real Fiori tenant. This time the timing-race step got its wait window widened (60s → 120s) instead of a text guess, and the flow converged to a pass within budget — the same scenario that used to end in budget-exhausted now passes.

Test plan

• cargo fmt --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace — green except the same pre-existing doctor_ai_e2e failure
• Live re-run of the multi-drift scenario against the real Fiori tenant, described above