BL-16822 Extract the canvas control menu rendering from the canvas component

[hatton]

CanvasElementContextControls owned both the decision of which controls to show and
the rendering of the menu that shows them. Inline (Word-style) images need the second
without the first: the picture's menu is the canvas element menu, item for item, but
the picture is not a canvas element and the canvas element manager knows nothing
about it.

So the rendering moves to its own module, canvasControlMenuRendering.tsx, and the
canvas component calls it. No behaviour changes and no inline-image code appears
here; this is the seam the rest of the stack builds on.

Two small things the same need turned up:

• getImageContainer treated an element whose img is a direct child, with no
  bloom-imageContainer, as having no container. That is the shape of a legacy image
  and of an inline image, and it is already the fallback
  buildCanvasElementControlRegistryContext uses for hasImage, so the two now agree.
• IControlContext gains an optional deleteThisObject, for an object that is not a
  canvas element and whose deletion means more than removing one element. Left out,
  Delete removes the page's active canvas element as it always has.

Card: https://issues.bloomlibrary.org/youtrack/issue/BL-16822

---

🤖 Generated with Claude Code

https://claude.ai/code/session_014DCBGajN5YyAYPBenEf1yy

Devin review

---

This change is 

[hatton]

[Claude Opus 5 (1M context) from Hatton's machine during devin-review]

Consulted Devin on 2026-09-07 12:46 MDT up to commit c3c2161856.

It raised 2 things. Each has its own review thread with the reasoning and the outcome; in short:

• Custom toolbar completion gap — real, and now said out loud: a control that draws its own toolbar bypasses the after-a-command hook, so the comment on it no longer claims to cover every command. Fixed.
• PR targets the wrong base — not an issue; this work targets master (6.6) by the developer's decision.

The fixes were amended into this branch after the review, so the commit above is not the current head; a fresh review is running against the new one. The only GitHub check on this PR is pr-automation (the review trigger), which passed; the front-end unit suite (915 tests), the C# spreadsheet tests (415) and the end-to-end suite (85) were all run locally and are green.