docs(sandbox): drop the from_registry workaround and fix the retry advice

[r33drichards]

docs(sandbox): drop the from_registry workaround and fix the retry advice

cua-sandbox 0.3.3 gives from_registry the os_type and kind keywords that
from_file already had (#3154), so the dataclasses.replace() reach-around is
gone from the snippet and the frozen-dataclass explanation with it. The version
floor moves to 0.3.3, which is also the first release with the pull-secret fix
that lets Fleet boot an image from a registry outside its own allowlist.

Also corrects the retry advice, which was wrong. It said a fresh sandbox name
avoids the 403 on update template. Four boots of the same image say otherwise:

same name after a failed boot   -> 403 update template
fresh name (e2e-fleet-cd-1)     -> 403 update template
fresh name (e2e-fleet-cd-2)     -> READY in 187 s
fresh name (mc-ghcr-fleet2)     -> READY in 157 s

Two fresh names disagreeing rules out the name as the cause. What holds is the
policy — both branches of the gateway rule are guarded by
input.method != "PATCH", so any update is refused — and that the failure is
intermittent. The page now says retry, rather than prescribing a fix that does
not reliably work.

Re-tested end to end against the released package in a clean venv, using the
page's snippets verbatim: from_registry(..., os_type="windows", kind="vm")
builds correctly on 0.3.3, and the local boot of
ghcr.io/trycua/minecraft-agent:1.20.1 reached READY in 248 s with
sb.exposed_ports returning {3000: 56457}.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

Verified against the released 0.3.3 in a clean venv, not a working tree — the page must be true for what pip install gives a reader.

🤖 Generated with Claude Code