Settle process-signal races across the services layer

A Process's exited and streamFinished signals aren't guaranteed to
fire in order, and several services decided an outcome on whichever
fired first: KdeConnect could report a successful file transfer as
failed if exited landed before the real stdout payload; Clipboard
could present a failed history query as an empty-but-healthy one;
Brightness could strand the last queued write of a drag; SoundFeedback
and SystemLocale could drop or misapply a rapid second toggle/click
because re-arming an already-running Process is a no-op. All five now
wait for both signals and let the authoritative one decide, matching
the pattern HomeAssistantConfig.qml already used correctly.

Health's "copy report" never enabled stdin, so it copied nothing
while claiming success. Capture announced every recording as saved
regardless of the recorder's actual exit code. Connectivity never
restarted Bluetooth discovery when the adapter was enabled from an
already-open page. CalendarAgenda left the UI in "loading" forever if
its helper died at startup, and the helper itself could crash
unguarded instead of reporting unavailable. Geocoding silently
dropped a query typed while the previous one was still in flight.
Notifs leaked tracked-but-undisplayed notifications under Do Not
Disturb, and dismissAll() skipped them.

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

config/dot/quickshell/services/Connectivity.qml

@@ -146,4 +146,11 @@ Singleton {
     onWifiDeviceChanged: root.syncScanners()
     onWifiEnabledChanged: root.syncScanners()
     onAdapterChanged: root.syncScanners()
+
+    // adapter.enabled has no property on root to bind onXChanged to, so it
+    // needs its own Connections -- the Bluetooth equivalent of onWifiEnabledChanged.
+    Connections {
+        target: root.adapter
+        function onEnabledChanged(): void { root.syncScanners(); }
+    }
 }