Document: disableRetries/maxAttempts bound only defect/invoker retries, not a handler-thrown RetryableError loop

Observed behavior

On the pinned restate-server floor, the test-harness disableRetries mode and the per-handler maxAttempts retry policy bound only the defect / invoker retry path. They do not bound a loop driven by a handler that keeps throwing a retryable error (Restate.retryable / RetryableError): such a handler re-arms indefinitely regardless of disableRetries / maxAttempts, because the retryable signal is the durable-step retry path, distinct from the invoker attempt budget those controls cap.

This is already noted in passing in the VRS sync audit; this issue tracks the follow-up to (a) document the distinction clearly in the user-facing guides, and (b) confirm whether this is intended Restate retry semantics or worth raising as an upstream question.

Scope

• Document the disableRetries / maxAttempts vs. handler-thrown-RetryableError distinction in the testing + error-boundary guides (what each control actually bounds).
• Determine whether the behavior is intended Restate semantics (durable-step retries are deliberately not bounded by the invoker attempt budget) or a surprising interaction worth an upstream question; capture the conclusion.

Notes

Possible upstream relevance — keep this as a standalone item so an upstream question can carry its own state if needed.

Refs #757.

Start by reading the testing and error-boundary guides and the VRS sync audit referenced in the issue; no specific file or test is named. Document what disableRetries and maxAttempts bound versus handler-thrown RetryableError retries, then record whether the behavior matches intended Restate semantics or warrants an upstream question.