lock: wake only on click or key, not pointer motion

[jte369]

Summary

While the lock view is active, the background MouseArea wakes the display on any pointer position change (onPositionChanged: root.wakeRequested()), not just on deliberate input. That means:

• Nudging the mouse (or a jittery device generating pointer events) while the locked display is blanked immediately re-lights the password prompt.
• The wake also re-arms the lock service's 5 s re-blank timer, so on setups where the lock surface is recreated under a stationary cursor (e.g. an external monitor that re-enumerates after DPMS sleep re-adds the output with a fresh surface) the screen enters a wake/blank cycle with no user input at all.

Wake should happen only on deliberate interaction: a mouse click or any keyboard input. Those wake paths are unchanged (onClicked, password field onTextChanged, Keys.onPressed), and because they still go through runWake()/armBlankTimer() the existing 5 s re-blank semantics are preserved.

Change

Remove the single onPositionChanged: root.wakeRequested() handler from the lock view's background MouseArea. Click and key wake are untouched.

Behavior

Before: moving the pointer over the locked, blanked display turns it back on.
After: a click or any key lights it to the password prompt; pointer motion alone keeps it dark.

Testing

./test/shell passes; the lock-area tests (video-background-test.sh, lock-fingerprint-indicator, lock-password-overflow fixtures) pass. Five unrelated files fail on this machine for environmental reasons (config-test, locate-test, omarchy-kernel-migration-test, snapper-test, unowned-system-paths-test) — none reference the lock plugin. Verified live on Omarchy 4.0.3-1: with the handler removed, locked-screen mouse motion no longer wakes it while clicks and keypresses still do.