Decide whether the other screens join in on workspaces

GNOME's Multitasking panel asked one workspace question worth reproducing, and
it is not which workspace goes on which screen. It is whether the second screen
participates at all: workspaces on the primary display only, or each screen with
its own. Ten rows of per-workspace assignment would be more powerful and worse.

Off is Hyprland's own behaviour and emits nothing. On pins workspaces 1 to 10 --
however many ALT+1..ALT+0 actually reach, read from keybinds.lua rather than
written down twice -- to whichever output is recorded as primary. With no
primary recorded, nothing is pinned: guessing one would move every workspace
onto whichever output happened to sort first, and this machine is in exactly
that state.

Applying is a reload, which is the part that shaped the design. Hyprland reads
workspace rules at config time and will not remove one afterwards -- a rule
written with an empty monitor keeps its old binding, which was checked rather
than assumed. Only a reload clears them, so the config is the only honest source
and the page cannot pretend a change has landed before one happens. Hence a
service that reads `hyprctl workspacerules` back rather than inferring success
from having written the preference, and a Reload row that exists only while the
two disagree.

Verified end to end against the live compositor and put back: off emits nothing,
on emits ten rules naming the primary, and turning it off clears them. The
settings file came back byte-identical.

Claude-Session: https://claude.ai/code/session_01Q84axqUE5inJhf5Jz9CFy1

config/dot/quickshell/modules/settings/DisplaysPage.qml

@@ -321,6 +321,51 @@ SettingsPage {
         }
     }
 
+    // Only with something to spread across. On one screen the choice has no
+    // meaning, the same way the Touchpad card stays hidden without a touchpad.
+    SettingsCard {
+        visible: Displays.monitors.length >= 2
+        title: "Workspaces"
+        subtitle: "GNOME asked this too. Off, every screen has its own workspaces and switching moves the one you are looking at; on, workspaces belong to the primary display and the others keep a screen of their own."
+
+        SegmentRow {
+            label: "Where workspaces live"
+            detail: Workspaces.applied
+                ? (Workspaces.primaryOnly
+                    ? "Workspaces 1 to 10 are on the primary display."
+                    : "Each display has its own workspaces.")
+                : "Chosen, but not in effect yet — the compositor has to reload."
+            options: [
+                { value: false, label: "All displays" },
+                { value: true, label: "Primary only" }
+            ]
+            value: Workspaces.primaryOnly
+            enabled: !Workspaces.reloading
+            divider: !Workspaces.applied
+            onSelected: value => Workspaces.choose(value === true)
+        }
+
+        // Appears only when the compositor and the preference disagree, which
+        // is also how it disappears: applying makes its own reason to exist go
+        // away. A reload is a whole-session event, so it is asked for rather
+        // than done quietly the moment the switch moves.
+        ActionRow {
+            visible: !Workspaces.applied
+            label: Workspaces.reloading ? "Reloading…" : "Reload to apply"
+            detail: "Re-reads the compositor's configuration. Windows and workspaces stay where they are."
+            action: "Reload"
+            enabled: !Workspaces.reloading
+            divider: false
+            onTriggered: Workspaces.apply()
+        }
+    }
+
+    SettingsCard {
+        visible: Workspaces.lastError !== ""
+        title: "Workspace problem"
+        subtitle: Workspaces.lastError
+    }
+
     SettingsCard {
         title: "Gaming display policy"
         subtitle: "Applied immediately and restored when the session starts."