Delay page saves for async canvas image resize (BL-16302)

[andrew-polk]

When adjustContainerAspectRatio waits for a newly changed image to load, it can update canvas geometry after changeImage() returns. That left a window where requestPageContent could save stale width, height, and position data.

Register a requestPageContent delay around that image-load retry, keep the existing paste-image wrapper for the separate async feature-status check, add a focused regression test, and update the C# comment that describes the async save behavior.

---

This change is 

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}

[greptile-apps]

Greptile Summary

This PR fixes a save-race window where adjustContainerAspectRatio could update canvas geometry (width/height/position) asynchronously — after the browser loads a newly changed image — while a requestPageContent save was already in flight with the old values. The fix extracts the async retry into waitForImageAndAdjustContainerAspectRatio, which registers a requestPageContent delay before yielding control and removes it in a try/finally after the geometry updates complete.

• waitForImageAndAdjustContainerAspectRatio uses an adjustmentResumed flag to guarantee the delay is added once and removed exactly once, whether the load event or the 100 ms fallback timeout fires first.
• The existing wrapWithRequestPageContentDelay on the paste-new-element branch is preserved, since it covers a separate async feature-status check that precedes any element creation — the two guards are designed to overlap with no uncovered window.
• EditingModel.cs comments are updated to reflect that delay registration is now spread across multiple sites rather than a single wrapper.

Important Files Changed

Filename	Overview
src/BloomBrowserUI/bookEdit/js/CanvasElementManager.ts	Extracts the async image-load retry into waitForImageAndAdjustContainerAspectRatio, which now registers addRequestPageContentDelay before yielding and removes it in a try/finally after resuming. The adjustmentResumed flag correctly prevents double execution when both the timeout and load event fire. The constant delay ID works correctly because the activeDelays array supports duplicate entries. The video loadedmetadata path at ~line 2856 is left without equivalent delay protection (pre-existing, noted in comment).
src/BloomExe/Edit/EditingModel.cs	Comment-only update to UpdateImageInBrowser: generalises the description from the single wrapWithRequestPageContentDelay wrapper to the broader 'code registers requestPageContent delays' pattern, accurately reflecting the new multi-site delay registration.

Comments Outside Diff (1)

1. src/BloomBrowserUI/bookEdit/js/CanvasElementManager.ts, line 2852-2861 (link)

   Video async path still unguarded

   The video loadedmetadata branch takes the same async deferred-geometry path that this PR fixes for images — it registers a listener and returns, meaning any save that fires before loadedmetadata would capture stale geometry. The comment here acknowledges the path is untested and "dimensions seem to always be available," but if they ever aren't, the same race applies. Since the image and video paths share the same "return early, fix later" structure, it would be worth wrapping the video listener with the same addRequestPageContentDelay / removeRequestPageContentDelay bookkeeping — or at minimum adding a TODO comment noting the gap.

_{Reviews (1): Last reviewed commit: "Delay page saves for async canvas image ..." | Re-trigger Greptile}

[JohnThomson]

@JohnThomson reviewed 2 files and all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on andrew-polk).