## Summary

The bar-widget sandbox added in the 4.0.2 → 4.0.3 window removes the bar's drag
properties from what a third-party bar widget can see, which silently breaks any plugin
that participates in bar drag gestures. [omarchy-tray](https://github.com/TyRichards/omarchy-tray)
— whose entire feature is "drag any bar widget into the tray's drawer" — went from
working to reorder-only across the upgrade, with nothing logged at all.

This is a sibling of #10888 (same `injectProps()` change, different missing surface) and
of #10863 / #10908. As in #10888, I am not arguing the sandbox is wrong. It is a clear
improvement. This is about a capability that had no sandboxed replacement, and about the
failure being completely silent.

## The change

`shell/plugins/bar/Bar.qml`, `injectProps()`:

```qml
// r2044 (Bar.qml:1769)
if ("bar" in target) target.bar = root

// r2083 (Bar.qml:2002)
if ("bar" in target) target.bar = firstParty
  ? root : root.pluginBarApiFor(pluginApiId, moduleName, registered)
```

`shell/Ui/PluginBarApi.qml` is new in r2083 — it does not exist in the r2044 package at
all:

```
$ bsdtar -xf omarchy-dev-4.0.0.r2044.gd7c783e-1-x86_64.pkg.tar.zst \
    usr/share/omarchy/shell/Ui/PluginBarApi.qml
bsdtar: usr/share/omarchy/shell/Ui/PluginBarApi.qml: Not found in archive
```

The real `Bar` root declares the drag surface at `Bar.qml:93-105`:

`barDragSource`, `barDragTarget`, `barDragTargetGeometry`, `barDragAfter`,
`barDragWindow`, `barDragScreen`, `barDragImageUrl`, `barDragSceneX/Y`,
`barDragScreenX/Y`, `barDragOffsetX/Y`.

`PluginBarApi` forwards none of them. It declares `foreground`, `barForeground`,
`background`, `urgent`, `fontFamily`, `position`, `vertical`, `barSize`, `transparent`,
`foregroundAnimationEnabled`, `centerSectionRevealHeld`, `activePopout`, `clickTargets`,
`layoutConfig`, plus the tooltip/click-target/popout hooks — and no drag property.

## Why it fails silently

A plugin reads the drag state two ways, and both degrade quietly:

1. Property reads return `undefined`. omarchy-tray's eligibility check is
   `return !!win && root.bar.barDragWindow === win`, which is now permanently false.
2. `Connections { target: root.bar; ignoreUnknownSignals: true }` — `PluginBarApi` has no
   `barDragSourceChanged` signal, so `onBarDragSourceChanged` is discarded without a
   warning. `ignoreUnknownSignals` is the documented way to write a handler against a
   possibly-absent signal, so plugins doing the right thing get silence.

Confirmed by instrumenting the plugin's `onBarChanged`:

```
TRAYDBG barChanged bar=PluginBarApi_QMLTYPE_23(0x7f52ce53d740)
        hasDragSourceProp=false hasDragWindowProp=false
```

Across a full drag gesture, not one of the plugin's drag handlers fired.

Reordering still works, because `Bar.qml`'s own `modulePointer` MouseArea handles it
internally and never consults the widget. From the user's side the bar looks healthy —
widgets still drag and reorder — while the drop target silently no longer exists.

## Steps to reproduce

1. `omarchy plugin add https://github.com/TyRichards/omarchy-tray.git --enable --yes`
2. Replace the stock tray with it (`./install.sh` from the plugin dir, or swap the
   `omarchy.tray` layout entry by hand).
3. Drag any bar widget onto the tray.

**Expected** (r2044 behaviour): the tray highlights, an insertion marker appears, and on
release the widget is captured into the tray's drawer, moving from `bar.layout` into the
tray entry's `widgets` array.

**Actual** (r2083): the tray never reacts. The widget reorders within the bar as if the
tray were an ordinary widget. Nothing is logged.

## Suggestion

A read-only drag view on `PluginBarApi` would be enough for this class of plugin —
`barDragSource` (or an opaque handle plus the source's module id), `barDragWindow`,
`barDragSceneX/Y` — paired with a `dropRequested`-style signal so a widget can claim a
drop without touching bar internals. Bar-relative coordinates would fit the sandbox
better than scene coordinates.

Failing that, a warning when a third-party widget binds `Connections` to a signal the
facade does not expose would have turned this from a silent regression into a five-minute
diagnosis.

## System

- Omarchy: `omarchy-dev 4.0.0.r2083.gd504061-1` (channel: `edge`; broken)
- Last good: `omarchy-dev 4.0.0.r2044.gd7c783e-1`
- Hyprland 0.56.2, Arch, kernel 7.2.3-arch1-3
- Lenovo ThinkPad T490, Intel Core i5-8365U
- Single monitor (eDP-1, 2560x1440), so this is not the multi-monitor
  `barDragWindow` path