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

Overview

The Canvas editor route sets no _admin_route and isn't matched by CanvasThemeNegotiator::applies() (which only claims canvas.api.form.* routes or 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.

To reproduce: open the editor on a site whose theme disables system/base's js.module.css, add an image-typed prop, and note "Update widget" renders visibly instead of hidden.

Proposed resolution

Have applies() also claim canvas.boot.* routes, so the editor is built with canvas_stark rather than the front-end theme. canvas_stark 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.

User interface changes

n/a