Close two holes in the edit-access guard

An image added to a cloud strategy was checked for edit access before
its upload was staged, not after. A demotion during that durable write
let the image and its undo step be committed anyway, though its
placement would never be saved. addImage now checks again once the
upload is staged; when refused, it drops the staged upload and its bytes
(CloudMediaUploadQueueNotifier.discardStagedUpload) and places nothing.

A batch refused with FORBIDDEN was confirmed as lost edit access by a
shell read made with whatever session was signed in. After switching
from account A to B, A's batch refused for its account binding, then
B's refused read, paused A's work with "You no longer have edit access"
although A still had it. The confirmation now counts only when it reads
as the batch's own account and the session is unchanged when it
answers; otherwise the batch takes the old retry path.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
0cfefbc024Dara Adedeji committed on 10/13/2026, 3:53:38 AMparent7368576

Checks

All checks passed
5 files changedLine totals unavailable