Fix layer-shell surfaces unclickable/unpainted on a fractionally-scaled output

Reported live, in stages: general input sluggishness, then specifically
dock/bar buttons not responding on the secondary monitor. Root-caused
jointly with a peer session (dotfiles-16), who independently instrumented
AGS itself (both bar and dock report correct visible/realized/revealed
state - the client is asking for the right thing) and srdwm's own
layer_hit_test log (the dock received zero hits across ~40 minutes while
the same output's wallpaper and bar took hundreds).

Confirmed against smithay 0.7.0's own source (desktop/wayland/layer.rs::
arrange): LayerMap::arrange() divides the output's physical mode by its
own scale before arranging layers, so LayerMap::layer_geometry() is
logical, not physical. Two call sites used it as physical, this
compositor's convention everywhere else:

- input/layers.rs::layer_surface_under_layers compared the physical
  pointer position directly against logical layer geometry. On a
  sub-1.0 scale output, logical space is larger than physical, so a
  bottom-anchored dock's rect sat entirely past the pointer's reachable
  range - permanently unclickable. A top-anchored bar only lost its own
  right-hand end, which is what made this look like "the dock is
  broken" rather than a scale bug affecting every layer surface there.
- elements.rs::output_layer_elements pushed the same logical position
  straight into the physical framebuffer - for the dock, past the
  bottom edge entirely, painting nothing.

Both fixed the same way udev/platform.rs::monitors() and udev/outputs.rs
already fix the identical unit mismatch for usable-area computation
(existing precedent, not a new technique): multiply by output.
current_scale().fractional_scale(), rounding to the nearest physical
pixel, before use.

Also removed a temporary per-pointer-motion-event diagnostic log in
layer_hit_test, still live from an earlier debugging session and
explicitly marked for removal but never removed - a real, measurable
cost on the hot input path, likely the direct cause of the separately
reported general slowness.

Full workspace test suite and clippy clean.

0 files changed, 0 insertions, 0 deletions