feat: scale the whole session, not just the classroom's own windows

UI_SCALE only ever reached the surfaces we draw ourselves. Chrome stayed
tiny — its tabs, omnibox and menus are Chrome's own pixels, and Ctrl+
only scales page content, which is no use to a volunteer reading a
toolbar from across the room.

UI_SCALE is a property of the television, not of one program, so it now
sets sway's output scale, which every client is measured against.
classroom-scale runs first in the session and applies it. The display
mode is untouched: the panel stays at 1920x1080 and only the logical
coordinate space shrinks, which is what makes everything in it larger.

Our own surfaces stop scaling themselves. They are measured in the same
logical pixels sway is already scaling, so applying UI_SCALE again would
double it. SHELL_SCALE is that decision in one named place, and setting
it back to ui_scale(config) would restore per-surface scaling without
touching a template.

Measured at 1920x1080 with Chrome 152. Chrome's tab strip 40 -> 49 ->
59px against 1.0, 1.25, 1.5; sway's title bar 25 -> 31 -> 38px; the
classroom dock 74 -> 92 -> 110px. Everything scales once, together, and
1.0 is identical to no scaling at all.

Two tradeoffs, both measured rather than assumed. GTK 3 has no
fractional scaling, so at 1.5 it renders at 2x and sway scales down —
very slightly softer, invisible at classroom distance. XWayland is
softer too: terminal text at 1.5 showed about 50% more intermediate-tone
pixels than at 1.0. VLC is the only XWayland application here, and in
DVD mode none of its interface is on screen, only video from a 720x480
disc that is being upscaled regardless. Chrome is a native Wayland
client and stays sharp, which is what matters for reading.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/testing.md

@@ -21,14 +21,21 @@ before promoting to stable with `./update_stable.sh`.
 
 ## UI scale
 
-- [ ] `UI_SCALE=1.0` looks exactly as it did before scaling existed
-- [ ] `UI_SCALE=1.25`, then `sudo systemctl restart getty@tty1`:
-      dock, icons, clock and notifications all grow together
-- [ ] `UI_SCALE=0.8` shrinks them together
-- [ ] The reserved bottom strip grows and shrinks with the dock, and a
-      maximised Chrome window still stops above it
+UI_SCALE sets sway's output scale, so it scales the whole session.
+Change it, then `sudo systemctl restart getty@tty1`.
+
+- [ ] `UI_SCALE=1.0` is identical to a session with no scaling
+- [ ] `swaymsg -t get_outputs` shows the mode still 1920x1080 at every
+      scale, with only the logical size changing
+- [ ] At 1.25 and 1.5, **Chrome** grows: tabs, omnibox, toolbar icons,
+      menus and page content
+- [ ] Chrome's buttons are still easy to hit with the mouse
+- [ ] Dock, clock, notifications and the DVD bar grow by the same
+      amount — once, not twice
+- [ ] `UI_SCALE=0.8` shrinks everything together
 - [ ] A nonsense value (`UI_SCALE=banana`) still gives a working shell
 - [ ] An extreme value (`UI_SCALE=9`) is clamped, not obeyed
+- [ ] `journalctl` or the sway log shows `classroom-scale: session scale N`
 
 ## Reserved bottom shell (regression)
 
@@ -128,6 +135,8 @@ With `DVD_ENABLED=true`:
       clock included — no wallpaper visible anywhere, at any point
 - [ ] A spinner and "Loading DVD…" show while the disc spins up
 - [ ] No partial VLC window is ever visible against the wallpaper
+- [ ] The loading surface stays up until the disc menu is actually
+      showing — VLC's tiled black startup window is never visible
 - [ ] Video or the disc menu replaces the loading surface when ready
 - [ ] A disc that never opens still gives the desktop back (20s)
 - [ ] No VLC chrome anywhere: no menu bar, no fullscreen controller,