the back key: one C++ path, so a dialog closes too

A phone's back key did not close the settings dialog. A window-level QML
Shortcut never sees the key while a modal popup is up, and a desktop run says
so plainly: with the dialog open, Back left backLayer() at "settings", while
invokeMethod(win, "stepBack") closed it on the spot and Escape -- the popup's
own CloseOnEscape -- closed it too. So the key reaches the popup and never
reaches the shortcut map, which is why the drawer (no popup) closed fine and
hid the problem on a phone.

A Keys handler on the window's root item is no help either: nothing reached
it, the focused TextField keeps the key. So the key is read in C++, on the
application object but only for this window's events -- a filter installed on
the window itself was never called once, while the same key closed the drawer
through the shortcut, hence the application object.

With a layer open, the window's own backLayer() names it and stepBack() closes
it, press and release both taken; with nothing open the key is passed on
untouched, which is what leaves the window on a phone and does nothing on a
desktop. Main.qml keeps only those two functions: the Shortcut and
backHasLayer are gone, --uitest installs the same handler main() does, and the
back checks now drive the code the phone runs instead of a shortcut only the
test had.

The last check asks the phone's own question and can end the run without the
closing line -- the activity leaving takes the process with it, and every line
is flushed as it is written.

Desktop: 106 ok, 0 FAIL. Phone: 104 ok, 0 FAIL (two clipboard checks are
skipped on Android), and "after the last back: window visible 0".

app/qml/Main.qml

@@ -507,6 +507,42 @@ ApplicationWindow {
             win.statusText = ""
         }
     }
+    /* The back key a phone has instead of a mouse: it closes what is open, one
+     * layer at a time -- the dialog on top, then the sliding sidebar. With
+     * nothing open the key goes on to the platform, and a phone leaves the
+     * window (Qt finishes the activity), which is right for the last layer.
+     *
+     * Which layer that is, and whether there is one, lives in one place: the
+     * C++ side (app/src/ui/BackKey.cpp) reads `backLayer()` on every Back key
+     * and calls `stepBack()` -- not a QML Shortcut, which a modal popup never
+     * lets through. --uitest reads the same two functions. */
+    function backLayer() {
+        if (settings.visible)
+            return "settings"
+        if (ask.visible)
+            return "ask"
+        if (consent.visible)
+            return "consent"
+        if (win.navOpen)
+            return "drawer"
+        return ""
+    }
+
+    /* One layer back. The dialogs are closed on the next turn of the event
+     * loop: closing one from inside the key event leaves its modal overlay up
+     * in this Qt (the dialog says it is closed, the overlay still eats every
+     * click after it), which --uitest walks straight into. */
+    function stepBack() {
+        if (settings.visible)
+            Qt.callLater(settings.close)
+        else if (ask.visible)
+            Qt.callLater(ask.close)
+        else if (consent.visible)
+            Qt.callLater(consent.close)
+        else if (win.navOpen)
+            win.navOpen = false
+    }
+
 
     // ---- engine -> UI ----------------------------------------------------
     /* The signal handlers only forward: every one of them has a function