fix: the bar keeps its order when an application opens

On the laptop the browser jumped behind the disc player the moment it was
opened. 0.2.4 caused that, and the cause is two lines of the stock applet:

    main.qml:153  hideActivatedLaunchers: tasks.iconsOnly || ...
    main.qml:155  launchInPlace: tasks.iconsOnly && sortingStrategy === 1

For an icons-only bar the first is always true — a launcher is hidden the
instant its application starts — and the second is what puts the running
window back where the launcher was. It only does that at sortingStrategy
1. 0.2.4 set it to 0 to stop teachers dragging the icons about, so the
launcher vanished and the window was appended after the others.

Reproduced in the lab with a real Chrome window before changing anything,
and the bar read off the screen: Wonder Ink, the player, then the
browser. With 1 it is Wonder Ink, the browser, the player, through
opening, a second window, another application opening beside it, and
every close.

The launcher identity was suspected and cleared: only one browser button
appears, because google-chrome.desktop already carries Chrome's own file
name and StartupWMClass for exactly this reason.

THE COST, AND IT IS REAL. Manual sorting is also the only mode in which
MouseHandler.qml accepts a reordering drop, so a teacher who knows to drag
can rearrange the bar again. There is no value that gives both and no
Kiosk key that separates them. classroom-desktop-reset already rebuilds
the bar from the package at every login, so a drag never outlives the
session. docs/testing.md states the trade rather than burying it, and the
configuration escape is written down there too as still open.

tools/lab/order-check is the test this needed and did not have. 0.2.4
passed a full set of configuration assertions while the bar did something
else, so this one opens real application windows and reads the panel
strip as pixels — there is no image library in the lab, so it captures
PPM and names each icon by colour. Six checks, all of them behaviour.

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

config/plasma/lookandfeel/contents/layouts/org.kde.plasma.desktop-layout.js

@@ -116,20 +116,33 @@ if (DVD) {
 
 tasks.writeConfig("launchers", launchers.join(","));
 
-// THE ORDER STAYS PUT.
+// THE ORDER STAYS PUT WHEN AN APPLICATION OPENS.
 //
-// 0 is "do not sort", and it is what stops a teacher dragging the
-// launchers into a different order. Plasma's default is 1, "manually",
-// and manual sorting is the only mode in which the task manager accepts a
-// reordering drop at all — see MouseHandler.qml, which tests
-// tasksModel.sortMode === SortManual before it will move anything. The
-// classroom shipped without this line, so it had Plasma's default and the
-// bar could be rearranged by anybody who dragged an icon.
+// 1 is "manually", and it has to be 1. This is not a preference; it is
+// the only value at which the Icons-Only Task Manager keeps a running
+// application in its pinned position.
 //
-// This is the supported lever rather than a patched task manager: the
-// drop is refused by the applet's own code, not caught afterwards by
-// something of ours putting the bar back.
-tasks.writeConfig("sortingStrategy", 0);
+// 0.2.4 set this to 0 to stop teachers dragging the launchers about, and
+// that worked — and broke the order instead, which is the bug this
+// replaces. Two lines of the stock applet explain the whole thing:
+//
+//   main.qml:153  hideActivatedLaunchers: tasks.iconsOnly || ...
+//   main.qml:155  launchInPlace: tasks.iconsOnly && sortingStrategy === 1
+//
+// For an icons-only bar the first is ALWAYS true: the moment an
+// application starts, its launcher is hidden. The second is what puts the
+// running window back in the launcher's place — and only at 1. At 0 the
+// launcher vanished and the window was appended after the others, so
+// opening the browser moved it behind the disc player. Reproduced in the
+// lab with a real Chrome window, and fixed by this line; both measured.
+//
+// The cost is that manual sorting is also the only mode in which
+// MouseHandler.qml accepts a reordering drop, so a teacher can drag the
+// launchers again within a session. There is no value that gives both,
+// and no Kiosk key that separates them. classroom-desktop-reset rebuilds
+// this bar from the package at every login, so a drag never outlives the
+// session, and docs/testing.md records the trade rather than hiding it.
+tasks.writeConfig("sortingStrategy", 1);
 // Launchers stay together at the start of the row and running windows
 // appear after them, so opening or closing an application cannot move a
 // pinned icon. This is Plasma's default; it is written down because the