Canvas editor is built with the site's front-end theme, not canvas_stark

The Canvas editor route (canvas.boot.*) isn't matched by CanvasThemeNegotiator::applies(), which only claims canvas.api.form.* routes and use_admin_theme requests. So the editor shell falls back to the site's front-end theme instead of canvas_stark.

That hands a front-end theme's libraries-override control over the editor's admin UI. A theme that disables system/base's js.module.css removes .js-hide { display: none } from the editor, so anything core hides that way renders visibly — most visibly the media library widget's "Update widget" button on any image-typed prop.

The fix

applies() also claims canvas.boot.*, so the editor is built with canvas_stark instead. It already renders the editor's forms and overrides nothing in system/base, so core's js-hide/js-show survive — the admin theme would also fix the leak but drags Claro's/Gin's whole stylesheet into a React app that doesn't use it. determineActiveTheme() is untouched.

Verification

EditorFrontEndThemeIsolationTest (added here) asserts both the cause and the symptom. Re-ran against current 1.x: Tests: 1, Assertions: 10 — passes.

AI-Generated: Yes (Claude confirmed the defect was still present on current 1.x, cherry-picked and re-verified an earlier fix draft against it, and drafted this description.)

Testing instructions

• On a site whose theme disables system/base's js.module.css, open the editor and add an image-typed prop.
• Confirm "Update widget" stays hidden instead of rendering visibly.
• Confirm the media library dialog still opens, is styled, and lists media.

Closes #3592179