feat: work in the background, and ask before taking the mouse

[lacymorrow]

Juno acts on other apps without taking your cursor or your active window, so you can keep typing while it works. When a step genuinely cannot be done quietly, it asks first.

Why this was mostly wiring

The focus-free input stack was already written and merged: SkyLight SLEventPostToPid falling back to CGEventPostToPid, plus accessibility actions that work on background windows. It was connected to four actions (left, right and double click, and AX typing) and nothing else. activate_without_raise, the call that routes keystrokes to a background app, and the AX-observer call that stops Chromium and Electron suspending their accessibility tree when a window goes behind, both sat in the tree with zero callers.

The ten blockers, fixed

1. ensure_main_window_focus activated Juno itself immediately before injecting a click, on four of the click commands. Deleted, with its callers. right_click and mouse_move never called it, which was the proof it was unnecessary.
2. Phase 4 wired: activate_without_raise now runs on the keyboard paths, get_ax_observer_check_remote keeps Chromium and Electron accessibility trees awake while backgrounded.
3. Background variants for everything that was left: middle click, triple click, drag, mouse down and up, key, hold key, release key, type, and scroll. Scroll used to warp the real cursor to the target first; it now posts to the process with the location set on the event.
4. click_auto hard-coded every browser to cursor-warping simulation. Browsers now try the element path first and reuse the existing Chromium activation primer.
5. Reading a window's accessibility tree no longer activates the app it belongs to. The app-wide desktop engine now sees background and menu-bar apps and never activates.
6. focus(element) no longer raises a window or falls back to a coordinate click in background mode.
7. open_application no longer shells open -a purely to focus an app that is already running.
8. All of it gates on background_mode, default on. With it off, behaviour is exactly what it is today.
9. Falling back to the physical cursor is now an explicit outcome, not a silent slide. Every action returns its tier (accessibility, process_targeted, physical_cursor), and Ok(None) means "this needs your mouse".
10. mouse_move in background mode drives only the virtual cursor and never the real pointer.

Asking for the mouse

When a step needs the physical cursor and mouse control is "ask", Juno stops and asks in the conversation: what it wants to do, in which app, and that your cursor gets bigger while it works. Allow once, Always allow, Not now. Denial and the 60 second timeout both return a recoverable error naming another route, so the agent can carry on rather than stall. A run with no conversation on screen, from the scheduler or the cloud, also raises a system notification, or it would be asking nobody.

While Juno has the mouse: the system cursor enlarges (as it already did), and the bar shows a blue status dot, a hairline, and "Juno is using the mouse in Safari". An RAII guard raises and clears that state, so a panic cannot strand the indicator on.

After the first granted takeover, one offer, once per session: "Let Juno use the mouse without asking?" Yes, No, Don't ask again.

Settings, under Advanced

• Work in the background, default on.
• Mouse control: Ask each time, or Always allow.
• Show in Dock, default on. Off makes Juno a menu-bar app that never becomes frontmost.

Getting back a hidden app

Turning off the Dock icon toasts where Juno went. If someone later opens Juno from Applications while it is running, macOS sends a reopen: the first one or two say "Juno is already running, it lives in the menu bar", and three within a minute, which is what being stuck looks like, offers the two things that actually help: put the Dock icon back, or quit.

Fixed in review, worth knowing

• The mechanism that lets Juno type into a background app redirects keyboard focus to that app, and nothing handed it back, so your next keystrokes would have landed in the app Juno typed into, silently. A guard now restores focus on drop, to whatever app you are actually in.
• That restore then had a subtler bug: "give focus to whoever is frontmost now" hands focus to Juno's target if the redirect is what made it frontmost. The decision now takes the target and can never return it, so it is correct either way.

Verified

cargo fmt, cargo clippy -D warnings on both crates, 519 Rust tests, 238 frontend tests, bunx tsc --noEmit. New unit tests cover tier selection, the consent state machine (an unknown decision string is a refusal, never consent), background-mode gating, the focus-restore rules, and the reopen escalation window.

Needs a hands-on pass on hardware

Three things cannot be proven without a running app, and all three degrade to today's behaviour rather than breaking: that SkyLight really routes keystrokes into a backgrounded Chrome or VS Code, that the private AX-observer registration really stops Chromium suspending its tree, and that a process-targeted scroll lands in the right view. The specific check: type into a backgrounded Chrome while an editor is focused, then confirm your next keystroke still lands in the editor.