Stop two contracts from driving each other's shell

settings-hyprland-write-contract failed in full suite runs and passed on
its own, reporting "a typed batch did not reach the compositor" with
every value at its default.

Both it and settings-commit-reset-contract drive the same harness file,
and Quickshell identifies an instance by its config path -- not by the
environment it was launched with. So when one run's instance has not
fully exited, the other's wait for `ipc show` is satisfied by that
instance's target, and the whole contract then talks to a shell it did
not start.

The two directions fail differently, and the second is the alarming one:

  The write contract lands on the isolated instance, whose compositor
  write seam is deliberately stubbed. Its writes go nowhere, which is
  exactly the symptom above.

  The commit/reset contract lands on the non-isolated instance and
  drives the DAILY DESKTOP's real compositor while believing it is
  isolated.

Both now refuse to start while another instance of that harness is
alive, and say which hazard they are avoiding rather than failing on an
assertion much later.

One trap worth naming, since it bit me writing this: `rg -c` prints
nothing at all when there are no matches, so an unguarded command
substitution yields "" and not "0" -- the first version of the guard
fired on a perfectly clean machine.

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

tests/quickshell/settings-hyprland-write-contract.sh

@@ -77,6 +77,32 @@ target_auto_hdr_int=$([[ "$target_auto_hdr" == true ]] && printf 1 || printf 0)
 target_vrr=$([[ "$original_vrr" == 3 ]] && printf 0 || printf 3)
 target_direct=$([[ "$original_direct" == 2 ]] && printf 0 || printf 2)
 
+# settings-commit-reset-contract drives the SAME harness file with
+# PANAMA_SETTINGS_TEST_ISOLATE_COMPOSITOR=1, where the compositor write seam is
+# stubbed out. Quickshell identifies an instance by its config path, so if that
+# run's instance has not fully exited, the `ipc show` wait below is satisfied by
+# ITS target -- and every write in this contract lands on the isolated instance
+# and never reaches the compositor. That is exactly what "a typed batch did not
+# reach the compositor" looks like when this fails in a full suite run but
+# passes on its own.
+#
+# So wait for the harness to be clear first, and say so plainly if it is not,
+# rather than silently talking to the wrong shell.
+harness_instances() {
+    # rg -c prints nothing at all when there are no matches, so an unguarded
+    # substitution yields "" rather than "0" and every comparison against a
+    # count fails.
+    local count
+    count="$(qs list 2>/dev/null | rg -c "^  Config path: $harness\$" || true)"
+    printf '%s' "${count:-0}"
+}
+for _ in $(seq 1 50); do
+    [[ "$(harness_instances)" == "0" ]] && break
+    sleep 0.1
+done
+[[ "$(harness_instances)" == "0" ]] \
+    || fail 'another instance of the settings harness is still running -- this contract would talk to it instead of its own, and its writes may be deliberately stubbed'
+
 XDG_CONFIG_HOME="$config_home" qs -p "$harness" --daemonize >/dev/null
 for _ in $(seq 1 40); do
     if qs_for_harness ipc show 2>/dev/null | rg -q '^target settings-system-test$'; then