### System details

ASUS Zenbook S16 UM5606WA, AMD Ryzen AI 9 HX 370 / Radeon 890M, Omarchy 4.0.0-1, two displays

### What's wrong?

Changing an inline bar widget setting in `shell.json` works, and then silently undoes itself the next time that widget is re-created — which any plugin reload does, including a plugin that isn't in the bar. `shell.json` keeps the new value, so the file and the bar quietly disagree, with nothing in the log.

I hit it as a widget rendering differently on my two monitors at the same time, from one config file. Each monitor has its own slot, so they can be re-created at different moments and end up holding different values.

**Steps to reproduce**

1. Give any bar widget an inline setting in `shell.json` (e.g. `{"id": "omarchy.clock", "format": "HH:mm"}`).
2. Change that setting. The bar picks it up.
3. `touch` any file in any installed plugin under `~/.config/omarchy/plugins/`.
4. The widget goes back to the value it had when the layout was last built. `shell.json` still holds the new one.

Expected: a widget renders what `shell.json` says, however many times its item is re-created.

Visual:
<img width="75%" height="75%" alt="Image" src="https://github.com/user-attachments/assets/fa1ad718-b3d9-4a88-9eba-85e67f5115c0" />

**Cause**

`ModuleSlot` derives its settings from the entry the delegate captured at creation (`shell/plugins/bar/Bar.qml:1533`), and `applySettingsDelta()` (`:376`) deliberately skips the rebuild — it swaps the entry in the array and patches the live item only:

```qml
var item = slot.activeItem
if (item && "settings" in item) item.settings = settings
```

`slot.entry` still points at the old object, so `moduleSettings` stays stale and `injectProps()` re-injects it on the next re-creation.

The same guard has a second effect: a slot whose item is the `emptyModuleComponent` placeholder — which is what every slot falls back to while a plugin reloads — has no `settings` property, so a write landing in that window is skipped outright and never applied to anything. Sweeping the offset between a reload starting and the write, on stock 4.0.0-1:

```
offset   what the widget reported          outcome
0.1s     R1 -> UNSET -> BASE               applied, then rolled back
0.3s     UNSET -> BASE                     never applied at all
0.6s     UNSET -> BASE -> R3               applied and kept
```

**Fix**

I have a fix ready — +10/-1 in `Bar.qml`, plus a regression test in `test/shell.d/` that reproduces this against a throwaway shell instance the way `runtime-smoke-test.sh` does. It fails on `quattro` HEAD and passes with the change. PR to follow; happy to leave it to you instead if you would rather take it a different way.

**Related, not duplicates**

- #7635 and #6503 are in the same function, `injectProps()`, but are the read-only `moduleName` bug rather than this one. I hit those warnings too and am not re-reporting them.

**Diagnostics**

Left out deliberately: `omarchy-debug --no-sudo --print` is 38k lines here, and this is a logic bug in the bar that reproduces from a config change plus a plugin reload on any machine — the hardware section wouldn't say anything. Happy to run `omarchy-debug` interactively and post the `logs.omarchy.org` URL (24h expiry) if you'd like it on the record.

Small thing noticed while gathering it: `omarchy debug --no-sudo --print`, which `agents/skills/omarchy/contributing.md` recommends, isn't routed on 4.0.0-1 — `omarchy commands` rejects it. The `omarchy-debug` binary works.