docs: clarify when legacy call retries need a new key

[JJasonSun]

Summary

Clarify the existing legacy Calls retry contract in the v1 guide and example entry point:

Saved Call ID → read the existing call
Acceptance uncertain → reuse the original request and key
Confirmed rejection, cause resolved → new attempt with a new key

Explain that a saved v1 concurrency rejection can replay after capacity becomes available. Scope the guidance to /v1/calls and link to the separate v2 rules.

API contract

Not changed. This clarifies the existing legacy recovery table and persisted-creation-failure behavior. V2 docs, OpenAPI, SDKs and executable examples are unchanged; no package release or changeset is needed.

Evidence

• Before: the opening instruction said to keep a stable key; the saved-failure exception appeared later.
• After: the opening distinguishes acceptance uncertainty from confirmed rejection and illustrates saved-error replay with 429 account_concurrency_exceeded.
• Typecheck, build, static output verification, 13 deployment tests and result-reader checks passed. All 31 browser tests passed on the default preview port; the first run used a custom port incompatible with one existing test's hard-coded URL.

Merge Danger

Door: Two-way. Revert the two prose edits to restore the previous wording.

Blast Radius: Documentation. Only legacy retry guidance changes.