The unit runner answers what jsdom does not

[ExtraToast]

Parent

#1095

What to build

The frontend unit runner answers the browser questions jsdom leaves unanswered, so that installing Vuetify in the next ticket does not fail for reasons that have nothing to do with Vuetify.

Three gaps, measured on a scratch branch that installed the plugin: eleven test files fail because window.visualViewport is undefined and Vuetify's overlay positioning reads it bare; twenty-seven fail because a page rooted in an app-bar or main-content component has no layout ancestor to inject from; one fails because a lazily-rendered banner never intersects, jsdom having no intersection observer.

Two test files also define a local helper of their own named mount. Left alone, the conversion in the next ticket turns that helper into a call to itself. Aliasing the imported name is a two-line change here and a confusing stack overflow there.

None of this changes behaviour today. On main, with no Vuetify instance installed, the shims answer questions nothing asks and the layout wrapper wraps components that do not look for it. That is the point: it lands green and on its own, and it takes the next ticket's blast radius from about fifty files down to about twelve.

Acceptance criteria

• The unit setup supplies a visual viewport and an intersection observer alongside the media-query and resize-observer shims it already supplies
• Every unit mount is wrapped in the application layout component, so layout injection resolves wherever a component asks for it
• Neither test file that defines its own mount helper shadows the imported one
• yarn test:unit, yarn lint and yarn typecheck each exit 0, verified by exit code rather than by reading a summary line
• No test's assertions change

Blocked by

None (can start immediately).