Stop the keyboard and mouse panel depending on other windows

docs/point-scan.md

@@ -48,7 +48,7 @@ Drag retains the source and scans a destination on the same display without hold
 
 `point_workflow` separates point selection, menu navigation and typed action requests. Its current selection policy always opens the menu; a future auto-select policy can reuse `default_click` without changing the executor. No auto-select timer or setting exists. The reusable `scan_menu` defines stable action IDs and rows. Shared frames carry menu tiles, labels and highlight strips; all native windows remain click-through and nonactivating.
 
-The desktop view adds menu, menuSuspended, dragDestination, dragConfirmation and executing phases. Existing point phases, saved settings and Bluetooth commands retain their shapes. Foreground changes, display changes, mobile connections, switch editing/learning and shutdown cancel the workflow. Targets and foreground identity remain in memory and are never logged or emitted. Automated action tests use fake input only; physical Windows/macOS focus, scaling, target, scrolling and drag checks remain required for hardware qualification.
+The desktop view adds menu, menuSuspended, dragDestination, dragConfirmation and executing phases. Existing point phases, saved settings and Bluetooth commands retain their shapes. Mobile connections, switch editing/learning and shutdown cancel the workflow. A change of display or work area cancels point scanning and its menus. So does a change of the window in front, once a switch has moved or chosen anything in the scan, so that a point is never used on a window it was not chosen over. Until then a point scan follows whichever window is in front, and can run with none in front. If no window is in front at the moment of the first choice and one appears afterwards, the scan is cancelled. The keyboard and the mouse panel stay open through both kinds of change; see [the keyboard](qwerty-keyboard.md). Targets and foreground identity remain in memory and are never logged or emitted. Automated action tests use fake input only; physical Windows/macOS focus, scaling, target, scrolling and drag checks remain required for hardware qualification.
 
 The action menu uses a fixed grid of square icon tiles with labels beneath the artwork, on the same dark rounded panel chrome as the scanning keyboard (`TileRole::Panel`). A yellow border and amber background identify the current row or item. The same artwork is drawn on Windows and macOS. Menu titles stay above the shared panel when a scan opens a menu or changes submenus, without taking keyboard focus.
 

docs/qwerty-keyboard.md

@@ -16,7 +16,7 @@ The bottom control row starts with Close keyboard, followed by Letters, Navigati
 
 Modifier keys are pressed only around each emitted shortcut and immediately released. Selecting a locked modifier does not hold that operating-system key while the scanner runs. Ordinary characters use text injection; command combinations and navigation use native key events. Native shortcuts retain the operating system's layout semantics.
 
-The keyboard remains open when the foreground application changes, clears its modifiers and prediction buffer, and sends subsequent keys to the new foreground application. It closes when the display environment changes or its scan session ends. Failed input clears keyboard modifiers and requires Select to resume. Stop, disconnect and application exit use the shared deterministic input cleanup. Word prediction can be enabled in Scanning settings. Five suggestions appear on the Letters page. Selecting a suggestion inserts its missing suffix and a space. Prediction uses local, read-only data; no personal vocabulary is saved. See [word prediction](word-prediction.md) for context availability and validation.
+The keyboard and the mouse panel do not depend on other windows. They open and keep working when no window is in front. When the foreground application changes the keyboard stays open and keeps its modifiers, Caps and highlight, and sends subsequent keys to the new foreground application. Only what belongs to the text of one window is let go: the suggestions and prediction context, a space or capital the keyboard owns, and any input still held. Suggestions are unavailable while no window is in front. When its display or work area changes, for example when a taskbar hides, the keyboard moves to fit; if its display is removed it moves to the display under the pointer, and while the displays cannot be read it stays where it is. The mouse panel does the same on the display under the pointer. It closes when its scan session ends. Failed input clears keyboard modifiers and requires Select to resume. Stop, disconnect and application exit use the shared deterministic input cleanup. Word prediction can be enabled in Scanning settings. Five suggestions appear on the Letters page. Selecting a suggestion inserts its missing suffix and a space. Prediction uses local, read-only data; no personal vocabulary is saved. See [word prediction](word-prediction.md) for context availability and validation.
 
 ## Manual validation
 
@@ -27,6 +27,6 @@ Use synthetic text in Notepad and a browser on Windows, and TextEdit and a brows
 3. Test Ctrl+A/C/V on Windows and Command+A/C/V on macOS. Cycle once/locked/off, including Shift with another modifier, and confirm no modifier remains physically held between selections.
 4. Visit every page. Verify row/key highlighting, reverse movement, row escape, suspension/resume, returning to the beginning after a key and Close. Set Start again from to Where I selected and After a selection to Wait for Select for the keyboard, with automatic scanning; verify the highlight stays on the typed key, waits for Select, and returns to the beginning after a suggestion.
 5. Move the keyboard between the top and bottom. Check a scaled display and a secondary display, including negative coordinates. Verify the keyboard fits the work area and never activates its native windows.
-6. Switch foreground apps and verify the keyboard remains open with cleared modifiers and predictions. Disconnect remote scanning, change display configuration and close Switchify; verify overlays disappear and owned input is released.
+6. Switch foreground apps with a locked modifier and verify the keyboard remains open with the modifier, Caps and highlight unchanged and the suggestions cleared. Show the desktop so that no window is in front and verify the keyboard and mouse panel open and scan. Hide or move the taskbar or Dock and verify the keyboard moves to fit without closing. Disconnect remote scanning and close Switchify; verify overlays disappear and owned input is released.
 
 Automated tests use fake input adapters only. Native manual results must be recorded separately; compilation and unit tests do not establish live application compatibility.

docs/scanner-architecture.md

@@ -102,7 +102,7 @@ Rules that hold whatever is chosen:
 - `wait` has no effect in an area that is not automatic, except that point scanning always waits unless `automatic` is chosen.
 - A point scan that starts by itself still stops at the pass limit.
 
-A point scan that started by itself takes up whichever window is in front until a switch is used in it, because the click before it may have brought another window forward. From then on, a change of window ends the scan as usual. While such a scan has no window in front, it holds still for up to a second, then ends as usual.
+Every point scan takes up whichever window is in front, or none, until a switch moves or chooses something in it. A click may have brought another window forward, and a panel may just have closed. From then on, a change of window ends the scan as usual. A change of display or work area ends a point scan at any time. The keyboard and the mouse panel are not tied to any window or display; see [the keyboard](qwerty-keyboard.md).
 
 `keyboardWaitAfterTyping`, saved by earlier versions, still makes the keyboard wait. It applies only while the keyboard has no `nextScan` of its own and the shared value is `standard`. Settings no longer offers or changes it; the saved value is kept.
 

docs/word-prediction.md

@@ -99,7 +99,7 @@ For native validation, use disposable synthetic text in Notepad and a browser on
 2. Type `w`, then `a`, accept `water`, and continue typing. Existing or pasted text must never become prediction context.
 3. Change pages and docking, type punctuation and numbers, and return to Letters. Verify context survives these layout changes and Backspace edits the tracked buffer.
 4. Use external keyboard/mouse activity. Verify suggestions clear and a new first letter starts fresh context. Then type `hel`, press an arrow key, and type `l`: verify no suggestions appear and the badge reads “Suggestions resume next word” until a space is typed. Repeat with Retry predictions and with a shortcut in place of the arrow key.
-5. Change foreground apps with locked modifiers selected. Verify the keyboard stays open, modifiers and suggestions reset, and later keys go to the new app.
+5. Change foreground apps with locked modifiers selected. Verify the keyboard stays open, the modifiers stay locked, suggestions clear, and later keys go to the new app.
 6. Close the keyboard, stop scanning, disconnect and exit. Verify input releases and the prediction worker exits. After closing the keyboard one spare worker remains; reopen after a few seconds and within two minutes, and verify the loading badge clears almost immediately, then verify the spare exits after two minutes idle and when scanning stops. Test observer failure separately; typing should remain usable without predictions.
 
 Compilation and fake-adapter tests do not establish native application compatibility. Record live results separately.