[Remove Vuetify from Studio]: Remove Vuetify Layout components

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

Studio's frontend still uses Vuetify's page layout (VContainer, VLayout, VFlex, VSpacer, VContent) in 56 of 328 .vue files, spanning channelEdit, shared/common UI elements, channelList, and administration. This tracking issue coordinates replacing these components with <divs>s and plain CSS (using either flexbox or CSS grid as needed), as part of #5060.

Prior #5060 sub-issues in these same areas were specifically scoped to buttons, forms, dialogs, and similar individual components, with layout staying out of scope.

Scope

Included:

• Replacing VContainer, VLayout, VFlex, VSpacer, and VContent with plain CSS (regular styles and/or flexbox by default, CSS grid where the layout requires true grid behavior) across all files
• Work organized and submitted per page/workflow (not per component), matching #5060's existing convention, for easier QA

Excluded:

• Other Vuetify components (buttons, forms, dialogs, data tables, menus, etc.) — tracked in separate #5060 sub-issues
• settings — already fully migrated, no remaining usage
• Component update and replacement that is already tracked in other parts of the project that resolves these issues incidentally
• Creating new Studio or KDS wrapper/replacement components to solve this problem — this work is not intended to introduce new KDS components or vendor Vuetify components. If that comes up as the true best solution for a given scenario, it needs input from Marcella, Richard, and likely Alex before moving ahead.

Strategy

We will start with a few issues that are intended to stress-test particular areas of the approach: (1) does the page-by-page approach still make sense here? (2) does the overall approach for css/flexbox work and are there surprises that pop up?

1. Shared navigation & app shell elements first — AppBar.vue, MainNavigationDrawer.vue, ImmersiveModalLayout.vue, FullscreenModal.vue, AppError.vue, ChannelEditAppError.vue render on every page, so it will gives us a chance to test the div/flexbox swap here and check how the approach works for RTL, sticky headers, and responsive behavior in a fairly straightfowrad way.
2. At least one issue for a single layout with without wrapping or grid behavior should be able to swap directly into plain divs/flexbox.
3. Try out replacing a more complex page with CSS grid and see what works and what doesn't, what headaches we didn't anticipate (maybe CompletionOptions/index.vue)

Sequencing and complexity estimates from the pilot batch inform how the remaining files are grouped into subsequent task issues.

Testing Requirements

• Existing unit/component test suites pass
• No behavioral regressions, and minimal* visual regression (* yes this is subjective, some of it will need to be case by case in order to be practical)
• Pull requests include before/after screenshots (or recordings) of the affected page/workflow
• The PR author and reviewer/approver must both perform manual QA of the affected workflow before merge — the QA team cannot test until changes land in unstable

Acceptance Criteria

• All VContainer/VLayout/VFlex/VSpacer/VContent has been removed and replaced
• No functional or visual regressions beyond what's explicitly noted as acceptable

AI usage

Used Claude to survey Vuetify layout-primitive usage across the codebase (file counts, per-file complexity estimates, and workflow groupings) and to draft this issue. Honestly...re-wrote almost the entire issue after.

Start with the shared shell files named in the issue—AppBar.vue, MainNavigationDrawer.vue, ImmersiveModalLayout.vue, FullscreenModal.vue, AppError.vue, and ChannelEditAppError.vue—and review their Vuetify layout usage. Work page by workflow, run existing unit/component suites, perform manual QA, and provide before/after screenshots; done means no listed layout components remain without regressions.