Stop the live shell clobbering the write contract

This contract failed intermittently with "a typed batch did not reach
the compositor", reporting Panama's shipped defaults, and passed on
retry. The earlier guard against a lingering harness was not the cause --
no instance was alive.

Adding the writer's own error to the failure message settled it: the
writer reports NO error while the compositor holds defaults. A rejected
write leaves an error behind; a write that succeeded and was then
overwritten does not. Both this contract and the LIVE shell write to the
same compositor, and the running Panama re-applies its own preferences
on any store change -- landing exactly the values that were being
mistaken for "the write never happened".

So the apply is re-issued periodically while waiting, which makes the
test survive being overwritten without weakening what it asserts, and
the failure message now distinguishes the two cases instead of
describing both as a write that never arrived.

The wait is also 10 seconds rather than 4. The write path verifies every
option by reading it back and retries a refused batch, so a loaded
machine legitimately takes longer -- and this runs in a suite alongside
other tests driving the same compositor.

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

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

@@ -149,8 +149,23 @@ sleep 0.3
 qs_for_harness ipc call settings-system-test applyJson \
     '{"windowRounding": 7, "gapsOut": 23, "blurEnabled": false, "inactiveOpacity": 0.85}' >/dev/null
 
+# 10 seconds, not 4. The write path verifies each option by reading it back off
+# the compositor and retries a refused batch, so a busy machine legitimately
+# takes longer than a quick apply -- and this contract runs in a suite alongside
+# other tests driving the same compositor. Failing at 4 seconds reported a
+# product bug ("did not reach the compositor") for what was queueing.
+# Re-issued periodically, because this contract and the LIVE shell both write to
+# the same compositor. When the running Panama re-applies its own preferences --
+# which it does on any store change -- it overwrites the values this test just
+# set, and the read-back below then sees Panama's shipped defaults with the
+# writer reporting no error at all. That combination is the signature: a
+# rejected write leaves an error, a clobbered one does not.
 typed=false
-for _ in $(seq 1 40); do
+for attempt in $(seq 1 100); do
+    if (( attempt % 30 == 0 )); then
+        qs_for_harness ipc call settings-system-test applyJson \
+            '{"windowRounding": 7, "gapsOut": 23, "blurEnabled": false, "inactiveOpacity": 0.85}' >/dev/null
+    fi
     if [[ "$(read_option decoration:rounding)" == "7" \
        && "$(hyprctl -j getoption general:gaps_out | jq -r .css | awk '{print $1}')" == "23" \
        && "$(hyprctl -j getoption decoration:blur:enabled | jq -r .bool)" == "false" \
@@ -161,10 +176,14 @@ for _ in $(seq 1 40); do
     sleep 0.1
 done
 if [[ "$typed" != true ]]; then
+    # Report what the writer thinks as well as what the compositor holds. Those
+    # two disagreeing is a rejected write; both showing defaults is a write that
+    # never happened, and the messages should not look identical.
     fail "a typed batch did not reach the compositor: rounding=$(read_option decoration:rounding), \
 gaps=$(hyprctl -j getoption general:gaps_out | jq -r .css), \
 blur=$(hyprctl -j getoption decoration:blur:enabled | jq -r .bool), \
-opacity=$(hyprctl -j getoption decoration:inactive_opacity | jq -r .float)"
+opacity=$(hyprctl -j getoption decoration:inactive_opacity | jq -r .float), \
+writer-reported error=\"$(qs_for_harness ipc call settings-system-test status | jq -r .lastError)\""
 fi
 
 # Verification must recognise those shapes as success, not report them rejected.