docs(sandbox): file the provisioning-row reaper as an open task
Adds the missing task to docs/cloud-sandbox-considerations.md.
A create that dies between inserting the cloud_workspaces row and reporting the sandbox leaves that row in provisioning forever: the sidebar shows a workspace that can't open, access refuses it because the status isn't ready, and nothing ever looks at the row again.
This isn't hypothetical — a production create hit the API function's 60s limit mid-bootstrap (fixed in #6555), and the row outlived the sandbox it named. Provisioning is ~5s now, so the window is small rather than closed: a killed function, a provider timeout or a crash still lands there.
Wanted: a sweep that fails rows older than a few minutes and tears down any sandbox they name, plus the same teardown on the paths that can't currently reach it.
Summary by cubic
Documents the open task to reap cloud_workspaces rows stuck in provisioning after a failed create, to prevent unusable workspaces and orphaned sandboxes. This records a real incident and outlines the desired sweep/teardown behavior.
- Describes the failure mode: the create inserts the row but dies before reporting the sandbox (e.g., API function 60s timeout).
- Specifies the fix: periodically fail rows older than a few minutes and tear down any named sandbox; apply the same teardown on error paths that cannot reach the sandbox.
- Notes current impact: the sidebar lists a workspace that cannot open,
accessrejects it as notready, and the row persists until manual cleanup.
Summary by CodeRabbit
- Documentation
- Documented a failure scenario where sandboxes may remain stuck in provisioning.
- Added guidance on handling inaccessible workspaces, cleanup gaps, timeout incidents, and stale sandbox removal.