Draw the menu bar in Compose, and give the drawing layer a net

What the removal left open (4 commits).

Compose's MenuBar is a javax.swing.JMenuBar set on the window, so Swing draws
it and no theme reaches it; with no look-and-feel configured that meant the
default Metal menu above a themed window. The bar is drawn in the window now,
except on macOS, where the system bar is where that platform expects it. Two
renderers read one description -- mainMenuModel is a plain function of the
state, which also gives the menus their first tests. Closing the main window
quits the application again, and the window writes its size back to the
profile; both had quietly stopped working when the last JavaFX stage went.

Then Etappe 7. Four faults shipped in the settings-window branch alongside a
green suite of 382 tests, because not one of those tests drew anything: a
control that never redrew, a tab strip that clipped mid-word, a form taller
than its window with no way down, and colours that came from Material rather
than the stylesheet. One regression test per class, and the spec's acceptance
criterion is met rather than assumed -- each fault was put back deliberately
and the matching test watched to fail.

The CI had never run the suite at all; it does now, headless. What that took
was not Xvfb: skiko's native library links against libGL and only has to be
loadable, since the drawing tests render in software. Without the package the
whole Compose half of the suite dies with a message that reads like a missing
display. Found by running the job under act rather than on GitHub.

The six tests that open a real window skip headless by their own guard. The
summary step counts from the result XML and fails on failures there, because
this project's rule is never to infer a green suite from an exit code.

app-desktop/build.gradle.kts

@@ -20,6 +20,21 @@ dependencies {
     implementation(compose.material3)
     implementation(libs.sqlite.jdbc)
     implementation(libs.jlayer)
+    /*
+     * The Compose UI test harness, used through runComposeUiTest { } from ordinary Jupiter
+     * tests. Deliberately NOT ui-test-junit4: that one brings the vintage engine, and two
+     * engines on one classpath is how half a suite silently stops being run. Checked after
+     * adding this: the only engine resolved is junit-jupiter-engine. JUnit 4 classes are on
+     * the test classpath, but they were before this too — something else pulls them
+     * transitively — and with no vintage engine nothing executes them.
+     *
+     * The accessor is marked experimental by the Compose Gradle plugin, so the opt-in sits
+     * here — one place, for one dependency. What it buys is the only mechanism that can
+     * answer "did the value reach the screen": the state-level tests and the two settings
+     * coverage nets check that a setter is called, which is a different question.
+     */
+    @OptIn(org.jetbrains.compose.ExperimentalComposeLibrary::class)
+    testImplementation(compose.uiTest)
     testImplementation(libs.junit.jupiter)
     testImplementation(libs.mockito.core)
     testImplementation(libs.mockito.junit.jupiter)