feat: one setting per application, and never the shape of the machine

A laptop is going in for the women's Bible study, and the obvious way to
build that — a laptop profile that turns off the children's church
applications — is the wrong way. A laptop may well take children's church,
and a tower may well be a Bible study. Hardware cannot be allowed to
decide purpose, so every optional application gets a setting of its own:

    WONDERINK_ENABLED       already existed; behaviour unchanged
    DVD_ENABLED             new
    PARENT_CALL_ENABLED     new

and DEVICE_TYPE says only what the hardware IS. classroom-desktop-layout
never reads it, and there is a test that says so, because this is the rule
that will be under pressure the first time somebody adds a device.

All three default to true, so an existing classroom that has never heard
of any of them comes up exactly as it did before. The settings are
appended to device.conf by the same mechanism every other setting has
used, so an upgrade gains them without losing a byte an administrator
wrote.

The disc player is the one place hardware still votes, and it is a veto:
DVD_ENABLED can take the player away from a machine that has a drive,
nothing can put it on a machine that has none. A button that cannot work
is worse than no button.

The layout's launcher markers are replaced by a feature block of three
plain booleans. The old mechanism commented a line out of an array, which
worked for launchers and could not express Parent Call, because that is a
whole widget rather than one entry. Three booleans express both, and the
launcher list is now built from them in one fixed order, so a disabled
application closes the row up rather than leaving a gap, and the same
enabled set produces the same bar on every machine in the church.

Also here, because it is the bar and not a feature: sortingStrategy=0.
Plasma's default is 1, "manually", and the task manager accepts a
reordering drop only in that mode — MouseHandler.qml tests
tasksModel.sortMode === SortManual before it will move anything. The
classroom never wrote the key, so it had the default, and any teacher
could drag the launchers into a different order. This is the applet's own
lever refusing the drop rather than something of ours putting the bar back
afterwards.

The test now runs the layout the package actually ships, in node, with
Plasma's API stubbed, and asserts the launcher string that comes out.
Asserting against a copy of the file's text in the test was how the old
one worked, and a copy is a thing that drifts.

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

tests/test-deployment-support.sh

@@ -343,8 +343,13 @@ check("started at every boot", "WantedBy=graphical.target" in layout_unit)
 check("enabled by the package", "enable ekklesia-classroom-layout.service" in postinst)
 check("a drive plugged in later is noticed", 'ENV{ID_CDROM}=="1"' in udev)
 check("and the rules are reloaded on install", "udevadm control --reload-rules" in postinst)
-check("the login says so when the layout and the hardware disagree",
-      "the disc player=" in reset)
+# One direction only. A layout offering a player on a machine with no
+# drive is a button that cannot work; a machine with a drive and
+# DVD_ENABLED=false is an administrator's choice and not a fault.
+check("the login says so when a player is offered with no drive",
+      "has no drive" in reset)
+check("and reads the layout's own feature line to decide",
+      "var DVD = true" in reset)
 
 print()
 print("7c. the room's own popups")