## What happens

Press-and-hold on a widget in the bar's **center** section (clock, indicators, weather…) and the bar silently enters "move bar to another edge" mode. When the press ends, that mode is **never cleared**: `barMoveActive` stays `true` and the fullscreen `omarchy-bar-move-ghost` layer stays mapped for the rest of the session, permanently drawing the top-edge preview slab (a translucent slab plus a 1px `barForeground` border) over/under the bar.

The user-visible symptom is a strange outline/band across the bar that never goes away. Only `omarchy restart shell` clears it. It is easy to hit by accident — a click on a center indicator that lingers past `pressAndHoldInterval` (200 ms) is enough.

## Steps to reproduce

1. Move the pointer over a widget in the bar's center section (e.g. the clock).
2. Press and hold the left button for > 200 ms, drag down into the desktop, release.
3. Observe the leftover overlay:

```
$ hyprctl -j layers | jq -r '..|select(.namespace?)|.namespace' | sort | uniq -c
      2 omarchy-background
      2 omarchy-bar
      1 omarchy-bar-move-ghost      # <-- still mapped, forever
```

During the drag both ghosts are up (`omarchy-bar-drag-ghost` + `omarchy-bar-move-ghost`); after release only the *move* ghost is leaked. It survives menu open/close, theme changes and idle cycles; `omarchy restart shell` is the only recovery.

## Why

`plugins/bar/Bar.qml`:

- `modulePointer` (`Bar.qml:1650`) is a `MouseArea` with `anchors.fill: parent` and `propagateComposedEvents: true`, stacked above `CenterGestureArea` (instantiated at `Bar.qml:1306` and `Bar.qml:1351`).
- `modulePointer` takes the pointer grab on `pressed`, so `CenterGestureArea` never gets `onPressed`. But `pressAndHold` is a *composed* event, so it does propagate down — `CenterGestureArea.onPressAndHold` (`Bar.qml:1419`) fires and calls `startDrag()` → `root.beginBarMove()` (`Bar.qml:1404-1410`), setting `barMoveActive = true`.
- Because `CenterGestureArea` never held the grab, it never receives `onReleased` (`Bar.qml:1437`) or `onCanceled` (`Bar.qml:1445`), so neither `finishBarMove()` nor `clearBarMove()` ever runs. `barMoveActive` has no other reset path, and `BarMoveGhostPanel.visible` is bound to it (`Bar.qml:1225`).
- `modulePointer.onReleased` (`Bar.qml:1709`) leaves `mouse.accepted` at its default when the drag ended over no drop target, so nothing propagates either.

## Expected

The two gestures should not be able to run at once. Either:

- suppress the bar-move gesture while a module drag is in progress (and vice-versa), or
- have `modulePointer` call `root.clearBarMove()` from its own `onReleased`/`onCanceled`, so the move state can never outlive the press that started it.

A cheap belt-and-braces guard would be to also clear `barMoveActive` when no mouse button is held.

## System

```
Omarchy    4.0.0-1
Hyprland   0.56.2 (efb50993780079460b0cbed1363e2166a2de1d9f)
Quickshell 0.3.0 (28771c7c74b42e20afca0b1b63980cb46515537c, AUR quickshell-git)
Kernel     7.1.8-arch1-3
CPU        Intel i7-8665U
GPU        Intel UHD Graphics 620 (WhiskeyLake-U GT2) [8086:3ea0]
Bar        position "top", center layout: omarchy.indicators, omarchy.clock,
           omarchy.keyboard-layout, omarchy.weather, omarchy.system-update
Monitors   2x 1920x1080 @ scale 1
```