Harden lock lifecycle, recovery, and keyboard wake

[AFOliveira]

Preserve a live session-lock owner through plugin reload, disable/removal and service synchronization, and recover password focus after mapping or keyboard wake. This addresses the lock lifecycle and input paths behind #6888, #7106, #6858, #7467 and #8628; hardware-specific outcomes still need validation.

The integration keeps authentication services in the current private store and exposes only ownership booleans to lifecycle code. It preserves an owning locker, defers reload until unlock, retains bounded focus retries and serialized blank/wake behavior, and bounds restart shutdown with one monotonic deadline. Restart requires confirmed absence before launching a replacement and retains #9469's notification readiness check.

Installed VM testing caught and fixed an additional ordinary-restart regression: Quickshell returns No running instances. with status zero even in JSON mode. The dispatcher now recognizes only that exact successful result under a fixed locale; malformed output and query failures remain errors.

Integrate after #9469. This branch includes current Quattro and that prerequisite through an ordinary merge. It consolidates relevant work from #7169, #7572, #7471 and #7592 while retaining their authors as co-authors. The narrower focus-only #8869 overlaps and must be reconciled before applying both.

At final 4aea51f2ddf3bef230626cf23d182a38f2284d5d, independent Daybreak review found no remaining code blocker. Focused lock, reload, private-auth, restart, sleep, video and update regression suites plus 112 CLI checks passed. Actual candidate /usr/bin commands and QML in a disposable 4.0.2 VM passed normal restart with one replacement process, secure lock acquisition, rescan preserving its owner, refusal to restart an owned lock, and keyboard password unlock. Inspected screenshots and a short transition recording support the visual/focus smoke. Guest files were restored afterward.

Keep draft for affected-hardware validation: ASUS TUF keyboard wake, Strix Halo/multiple displays, physical DPMS, suspend/resume, hotplug, fingerprint and crash-recovery paths were not established on this final revision. Source tests and a single virtual display cannot establish those outcomes.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[azure-eller]

Reproduces here; the PR applies cleanly to current quattro, breaks nothing in the suite, and closes three more issues than its body lists.

ASUS TUF Gaming A16 (FA608UP), Omarchy 4.0.1-1, Hyprland 0.56.2-1, Quickshell 0.3.1-1, kernel 7.1.9, single panel on amdgpu. Every lid-open resume leaves the lock screen drawn but keyboard-dead; a click anywhere restores typing.

That symptom localizes it precisely: LockView.qml:118 onClicked calls forcePasswordFocus(), :119 onPositionChanged does not — so pointer motion wakes the display but never the keyboard. Not compositor seat focus. It is the one-shot grab this PR replaces: inputEnabled (Service.qml:277, bound to lockRequested) never toggles again for the life of a lock, so nothing re-arms it.

Checked before commenting:

• Both commits cherry-pick onto quattro @158e8cfb with no conflicts — the branch is 34 behind, but clean.
• test/all on the rebased branch: 212 of 217 files pass. All 5 failures fail identically on plain quattro from the same checkout path, so none are from this PR — 4 want a sibling omarchy-pkgs checkout, and windows-vm-mount-boundary-test.sh cannot run from any checkout under /home because it tmpfs-mounts over /home in its namespace. All 8 lock tests pass.

Also closes #8361, #8520, #7811 — worth adding to Fixes: so all eight clear on merge.

#8869 is the same bug with a narrower, unbudgeted retry; this supersedes it. Its one good extra, focus: true on the TextInput, would make a fine follow-up — not worth holding this up for.

[cyppe]

Real-world confirmation of the #7106 failure mode this PR targets: two stranded locks in 24 h on 4.0.2-1 (quickshell 0.3.1-1, Hyprland 0.56.2-1, AMD Strix Halo, dual monitor), both caused by a dotfile manager writing a local plugin over SSH while the desktop was idle-locked — full journal excerpts and versions in #7106. One detail that supports the "preserve the owning service / defer the reload" approach: the in-process recovery after the reload stalled indefinitely at lock-pending: screen-stabilizing, whereas a freshly launched shell process completed the same recovery to secure=true in ~6 s. Glad to test this branch's behavior with a plugin write while locked once it lands in a release.