feat: a lesson in Wonder Ink is the size the browser shows it, and zooms

Teachers found lessons in Wonder Ink too small next to the ordinary
browser. Measured by asking each page for devicePixelRatio: Wonder Ink
follows the display scale exactly (dpr 1.5 at 150%), and Chrome is
scaled TWICE (dpr 2.25) — under Plasma it follows the compositor itself
and classroom-browser also forces UI_SCALE, a flag from the sway session.

The browser is left as it is. Wonder Ink's pages start at zoom =
UI_SCALE, the room's own number (1.0 at 100%), and measured afterwards
match the browser: dpr 2.25 and 853 px against 2.25 and 854. The window
is not zoomed; Qt scales it once, correctly.

Ctrl+Plus/=/keypad, Ctrl+Minus, Ctrl+0, Ctrl+wheel and the right-click
menu set one level for every tab, remembered as LEVEL= in its own file,
relative to the room. Two actions on one key are ambiguous to Qt and it
then does neither — Ctrl+Minus did nothing until each command became one
action with all its keys, which also fixes Ctrl+Shift+Tab.

The engine profile is built by one function, which the lab's checks now
use: a check with its own profile showed every worksheet blank.

The lab fences 10.10.0.0/16 as well: the development host reaches the
real Elmer over Tailscale, and the lab provisions a queue pointing at it.
Four lab checks written for older code are corrected; one had failed on
every run since 0.2.3.

tools/lab/wonderink-zoom-check: 18 checks. Lab: converged 120, print 39,
worksheets 24, all passing.

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

docs/ui-scale.md

@@ -55,10 +55,15 @@ the display scale for itself asks that command rather than the file:
 * **Plasma** — the panel, the clock, notifications, the volume display and
   every dialog, because `classroom-scale` sets it as the display's scale
   through `kscreen-doctor` at every login.
-* **Chrome and Wonder Ink** — `--force-device-scale-factor`, because
-  Chrome on Wayland was measured not to follow the compositor's output
-  scale on its own. It is the same number, not a second scaling: Chrome
-  replaces its detected scale with it.
+* **Chrome** — `--force-device-scale-factor`, because Chrome on the sway
+  session was measured not to follow the compositor's output scale on its
+  own. **Under Plasma it does**, so this is now a second scaling: measured
+  at 150%, Chrome's pages report `devicePixelRatio` 2.25, not 1.5. Left as
+  it is in 0.2.6.1 because it is the size teachers know; see
+  [wonder-ink.md](wonder-ink.md#how-large-a-lesson-is).
+* **Wonder Ink** — its window follows the compositor as every Qt
+  application does, and its *pages* start at a zoom of `UI_SCALE`, so a
+  lesson is the size the browser shows it.
 * **The disc player's own surfaces** — they are measured in the logical
   pixels the compositor is already scaling, so they follow without being
   told.

docs/wonder-ink.md

@@ -276,11 +276,67 @@ logs it to the journal and carries on.
   `~/.local/share/ekklesia-classroom/wonderink`. The new one is
   `wonderink-shell` beside it, so rolling back to 0.2.0 finds the old one
   intact.
-* **One scale for the room.** Chrome has to be handed `UI_SCALE` because
-  it was measured not to follow the compositor on Wayland. Qt does follow
-  it — measured at `UI_SCALE=2.0`, where a Qt client on that session
-  reports `devicePixelRatio 2.0` without being told anything — so Wonder
-  Ink is deliberately *not* told, or the scale would be applied twice.
+* **One scale for the room** — see *How large a lesson is*, below.
+
+## How large a lesson is
+
+Teachers found lessons in Wonder Ink too small next to the same site in
+the ordinary browser. Measured in the lab (Plasma 6 on KWin, Debian 13) by
+asking each page for `window.devicePixelRatio` and its width in CSS pixels,
+with the display scale set the way a room sets it (`kscreen-doctor` and
+`UI_SCALE`):
+
+| Display scale | Wonder Ink 0.2.6 | Chrome, as `classroom-browser` starts it |
+| --- | --- | --- |
+| 100% | dpr 1, 1920 px wide | dpr 1, 1920 px wide |
+| 150% | dpr 1.5, 1280 px wide | **dpr 2.25**, 854 px wide |
+| 200% | dpr 2, 960 px wide | **dpr 4**, 500 px wide |
+
+Wonder Ink was right by the desktop's measure: it follows the display
+scale exactly, like the panel and every dialog. **Chrome is scaled twice.**
+Under Plasma it follows the compositor's scale itself, and
+`classroom-browser` also forces `--force-device-scale-factor=UI_SCALE` — a
+flag from the sway session, where Chrome was measured *not* following the
+compositor. So in any room above 100%, every page in the browser is
+`UI_SCALE` times larger than the desktop around it, and that is the size
+teachers read lessons at.
+
+0.2.6.1 does not change the browser — it is the size the rooms know, and
+changing it everywhere is its own decision. Wonder Ink's pages start at
+the browser's size instead: **page zoom = `UI_SCALE`**, the room's own
+clamped number, which is exactly 1.0 in a room at 100%. Wonder Ink's
+window, tabs and dialogs are not zoomed; Qt already scales them once,
+correctly. Measured after the change: at 150% the lesson reports dpr 2.25
+and 853 px, Chrome dpr 2.25 and 854 px.
+
+**The teacher's own size** goes on top: Ctrl+Plus (and Ctrl+=, and the
+keypad's), Ctrl+Minus, Ctrl+0 for normal, Ctrl+wheel, or the right-click
+menu. Chrome's steps, 50% to 300% of the room's normal size, one level for
+every tab including new ones. It is remembered in
+`~/.config/ekklesia-classroom/wonderink.conf` as a single `LEVEL=` line —
+its own file, nowhere near the engine profile, so remembering a size can
+never mean remembering a sign-in — and relative to the room, so an
+administrator changing `UI_SCALE` later still gets the right result.
+
+Measured along the way:
+
+* the engine keeps a tab's zoom across every navigation, same site or not,
+  so it is set once when the tab is made and never re-applied;
+* zoom does not change what prints: the same lesson is 3 pages at 100%,
+  200% and 400%;
+* **page zoom does not reach a worksheet tab.** Chromium's PDF viewer
+  follows the display scale like the window, fits the page to its width,
+  and has its own − / + zoom in its toolbar, which is what a teacher uses
+  there;
+* two Qt actions on one key are ambiguous and Qt does *neither* — Ctrl+Minus
+  did nothing while it was bound once by name and again as KDE's standard
+  zoom-out key. One action per command now carries all its keys, which
+  also fixed Ctrl+Shift+Tab (bound twice the same way since 0.2.1).
+
+`tools/lab/wonderink-zoom-check` asks the installed command all of this.
+The lab's injected keyboard does not reach its nested session, so the
+check delivers keys through Qt's own key path to the focused page; a
+physical Ctrl+Plus on a classroom keyboard is a hardware check.
 
 ## Turning it off