ChatRecoveryConfig.maxRecoveryWork docs retain old default and omit durable-segment unit

[ternarybits]

Describe the bug

ChatRecoveryConfig.maxRecoveryWork still documents the old default and an ambiguous unit after #2223 changed the meter to durable stream segments.

Validation scope

Source/API review on 2026-09-15 against the latest released train (@cloudflare/think 0.18.0, @cloudflare/ai-chat 0.12.0, agents 0.23.0; release commit 5f7ad7e4edac2ec8dd1d6a31758f251cb52373fa) and upstream main a7b29135acf127cdf4a44114652970d0a22300de. The missing contract described below remains in both. This is source validation, not a new production or workerd reproduction. Our current application uses Think 0.17.0 / ai-chat 0.11.0 / agents 0.22.0.

Source-level reproduction

1. Read ChatRecoveryConfig.maxRecoveryWork JSDoc: it says “produced content/tool units” and default 1000.
2. Read DEFAULT_CHAT_RECOVERY_MAX_WORK: the runtime value is 10_000.
3. Read the ai-chat 0.12.0 changelog: perf(chat): derive the recovery progress marker from the stream log #2223 explicitly states the unit changed to durable segments and the default moved from 1000 to 10000.

The release changelog does document the change. Our initial downstream note called it silent; that claim was incorrect. The remaining problem is the public configuration contract and migration guidance for explicit numeric overrides.

Expected behavior

• Correct the public type documentation to match the runtime default.
• Name the unit precisely in the type/API documentation: durably flushed segments (roughly ten packed streaming chunks per segment, settled tool results flushed immediately, plus explicit credits such as forwarded child progress).
• Explain that existing explicit maxRecoveryWork overrides are not automatically recalibrated and should be measured before carrying them across the upgrade; a blind 10x multiplier is not a universal equivalence.
• Consider a unit-explicit option/type or versioned unit contract so future representation changes are visible to callers.

We currently configure a custom budget of 100 in the preceding train. Copying that number unchanged changes its effective meaning under the new meter, even though TypeScript accepts it. This report does not claim a newly reproduced recovery failure; it is a directly verifiable documentation/API contract mismatch.