fix(planning): recalibrate the duration estimate to the faster engine

Rendered waits after #302, in throttled headless Chromium, were well
below the shown ranges: two years waited 1.9 s against 3-24 s, three
years 4.5 s against 11-68 s, and the loaded year 4.0 s against 4-26 s.
The prior keeps its structure with refitted, rounded constants,
400 + 250 x (D/365.25)^0.5 x (P/30)^1.5 x R, which stays within about
1.2 times of all six measured configurations. Five years with 30 days
per year now shows 6-37 s instead of 44-265 s. Local refinement is
unchanged.

The 4x CPU throttle slows only the main thread, not the planning
worker, so phones can still wait longer than these desktop samples.

Part of #302.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/benchmark/README.md

@@ -238,6 +238,76 @@ outcome, and delivery of its stable explanation. Confirm
 that editing an input remains possible during active worker CPU work. These
 measurements describe that device and workload; they impose no latency limit.
 
+## Indicative wait recalibration — 2026-10-18
+
+[Issue #302](issue-302.md) made planning much faster, so the rough prior
+behind the range beside **Calculate** (see
+[planning-duration.md](../planning-duration.md)) overstated every request with
+many obligation solutions or a multi-year horizon. These measurements refit it.
+
+The NEW builds are the production build of `75320da` (the #302 engine); the OLD
+column is the production build of `b356117`, the last commit before the #302
+engine changes. Both ran in headless Chromium 149.0.7827.55 on an AMD Ryzen 7
+7800X3D desktop under Debian 13 on WSL2. Emulation used 412×915 pixels, scale
+2.625, touch, reduced motion and 4× CPU throttling; external font downloads
+were blocked. **This is desktop emulation, not a phone measurement.**
+`Emulation.setCPUThrottlingRate` slows the page's main thread but does not
+throttle the dedicated planning worker, so the search ran at desktop speed.
+A phone, whose worker is also slower, can wait longer than any figure here.
+
+Every run used a fresh browser. The application's own initial calculation (one
+saved day) finished first. The run then enabled any custom rules with the real
+toggles and set the planning dates through the real date controls; the saved
+balances, rules and dates were checked, and the calendar stayed unchanged until
+one Calculate click. The wait is the time from that click to the displayed
+final placements with the loading overlay gone, the endpoint described in
+[planning-duration.md](../planning-duration.md). Every run returned a `Plan`
+with the placement count shown. NEW has three runs per configuration; OLD has
+two, and was not run for configurations 4 and 5. Configurations 1 to 3 give each
+year 20 CP and 10 RTT days available January 1 and expiring December 31; every
+configuration keeps the six default optimization presets, and 4 and 5 are the
+benchmark's "loaded year" and "typed obligations" scenarios from
+`benchmarkScenarios()`.
+
+| #   | Configuration                                         | Placements | NEW wait, ms mean [min–max] | OLD wait, ms mean [min–max] | Range shown, old constants | Range shown, new constants |
+| --- | ----------------------------------------------------- | ---------: | --------------------------- | --------------------------- | -------------------------- | -------------------------- |
+| 1   | One year 2024, 20 CP + 10 RTT                         |         30 | 730 [716–752]               | 1,014 [990–1,037]           | 1–5 s                      | 1–3 s                      |
+| 2   | Two years 2024–2025, 20 CP + 10 RTT per year          |         60 | 1,909 [1,880–1,943]         | 3,137 [3,121–3,153]         | 3–24 s                     | 1–7 s                      |
+| 3   | Three years 2024–2026, 20 CP + 10 RTT per year        |         90 | 4,477 [4,450–4,498]         | 8,250 [8,241–8,258]         | 11–68 s                    | 2–15 s                     |
+| 4   | Loaded year (6×12 days, 3 obligation + 2 preferences) |         72 | 4,024 [3,981–4,076]         | not run                     | 4–26 s                     | 1–12 s                     |
+| 5   | Typed obligations                                     |         10 | 640 [599–687]               | not run                     | 1–2 s                      | 1–2 s                      |
+| 6   | One year 2024, 5 CP only                              |          5 | 465 [457–472]               | 518 [518–518]               | 1–2 s                      | 1–2 s                      |
+
+The old ranges are the application's no-sample ranges before the change, and
+the new ones were confirmed in the rebuilt application for the same six saved
+configurations. The earlier 2026-10-05 references (1.74, 5.08 and about 11
+seconds) came from a different build, before many engine speedups, which is why
+the OLD column is lower than them.
+
+The refit keeps the model's structure and rounds its constants:
+`400 + 250 × (D / 365.25)^0.5 × (max(1, P) / 30)^1.5 × R`. With `D` the horizon
+in days, `P` the placement load and `R` the rule weight, it gives:
+
+| #   | `P` | `R` | `D`   | Old estimate, ms | New estimate, ms | Measured, ms | New / measured |
+| --- | --- | --- | ----- | ---------------: | ---------------: | -----------: | -------------: |
+| 1   | 30  | 1.9 | 366   |            1,443 |              875 |          730 |           1.20 |
+| 2   | 60  | 1.9 | 731   |            7,714 |            2,301 |        1,909 |           1.21 |
+| 3   | 90  | 1.9 | 1,096 |           22,444 |            4,675 |        4,477 |           1.04 |
+| 4   | 72  | 3.7 | 366   |            8,574 |            3,843 |        4,024 |           0.95 |
+| 5   | 10  | 2.9 | 366   |              636 |              540 |          640 |           0.84 |
+| 6   | 5   | 1.9 | 366   |              378 |              432 |          465 |           0.93 |
+
+Every measured mean lies well inside the unrounded range from half to three
+times the estimate. Configurations 1, 5 and 6 finished below the displayed
+minimum of 1 second, which the whole-second display cannot go under. Horizon
+length and placements grew together in configurations 1 to 3, so the data does
+not separate the 0.5 horizon power from the 1.5 placement power; the sum
+reproduces the roughly squared growth with years above a fixed overhead. The
+same prior estimates five years with 30 days per year (`P` = 150, `D` = 1,826)
+at about 12 seconds, displayed as 6–37 seconds; the old constants gave
+44–265 seconds. Horizons beyond three years remain unvalidated extrapolation.
+These samples set a rough prior and impose no duration ceiling.
+
 ## Historical measurements before trace removal
 
 The following records remain as evidence for their dated builds. Trace-related behavior and metrics below are superseded by issue #76.