fix(macos): recover cursor stranded off-screen after display change

[ShimmerGlass]

Summary

When the macOS display configuration changes while a remote client is controlling the Mac, the cursor can be left at a position that no active display covers. clamp_to_screen_space in input-emulation/src/macos.rs then can't find the current display. It logs could not get current display! and returns the position unchanged. Every later motion event hits the same path, so:

• the cursor is stuck and the warning floods the log,
• keyboard input still works,
• you can't return to the other machine, because the cursor never reaches the screen edge.

This PR adds get_nearest_display: when the cursor isn't on any display, it picks the closest active display (from CGDisplay::active_displays()). The cursor is then clamped onto that display, so the next motion moves it back on screen. The warning remains only for the case where macOS reports no active displays at all.

Related: #487 handles display hotplug on the capture side (input-capture/src/macos.rs). This PR fixes the emulation side, and the two don't overlap.

Testing

• cargo fmt, cargo clippy -p input-emulation --all-targets (no new warnings), cargo build
• Unit tests for nearest_display (selection logic extracted into a pure function over display bounds): no displays, point on a display, exclusive max edge, cursor left on a removed display, point off a corner. cargo test -p input-emulation passes.
• Not yet manually verified with a display change; the stuck state happens intermittently.

🤖 Generated with Claude Code

[grazzolini]

I believe this fixes another issue I found when using lan-mouse between 2 mac's, but I'll test. Essentially, the mouse jumps to the left portion of the client screen after crossing from the server. I can go back to the other machine, but the right portion of the client's screen remains an area that I can't interact with the mouse, until I restart lan mouse on the client.