### System details

AMD Ryzen 5 3500U / Radeon Vega Mobile, Omarchy 4.0.0.alpha, Hyprland 0.56.2

### What's wrong?

**Summary**

`omarchy-hyprland-workspace-layout-toggle` keys its persisted workspace rule by
workspace **id**. Hyprland gives *named* workspaces negative ids and reassigns
them every session, so the rule matches no workspace. `hyprctl eval` still
answers `ok`, so the script's `||` fallback never runs and it sends a success
notification for a change that did not happen.

**Mechanism**

```bash
ACTIVE_WORKSPACE=$(hyprctl activeworkspace -j | jq -r '.id')
[[ $ACTIVE_WORKSPACE =~ ^-?[0-9]+$ ]] || exit 1
...
printf 'hl.workspace_rule({ workspace = "%s", layout = "%s" })\n' "$ACTIVE_WORKSPACE" "$NEW_LAYOUT" >"$LAYOUT_FILE"
hyprctl eval "hl.workspace_rule({ workspace = \"$ACTIVE_WORKSPACE\", layout = \"$NEW_LAYOUT\" })" >/dev/null 2>&1 || \
  hyprctl keyword workspace "$ACTIVE_WORKSPACE, layout:$NEW_LAYOUT"
```

The `^-?[0-9]+$` guard accepts the negative id, so nothing fails loudly.

**Evidence**

Same workspace, same moment, two rules differing only in the selector:

```
# what the script wrote
hl.workspace_rule({ workspace = "-1340", layout = "dwindle" })
# tiledLayout afterwards: scrolling      <- unchanged

# same workspace, addressed by name
hl.workspace_rule({ workspace = "name:<monitor description>:1", layout = "scrolling" })
# tiledLayout afterwards: scrolling      <- applied
```

Directly:

```
$ hyprctl eval 'hl.workspace_rule({ workspace = "-1340", layout = "scrolling" })'
ok
$ hyprctl activeworkspace -j | jq -r .tiledLayout
dwindle
```

**It also never toggles back.** `CURRENT_LAYOUT` is re-read from `.tiledLayout`,
which never changed, so every press computes the same `NEW_LAYOUT`. Three
consecutive presses left three state files all saying `scrolling`, never
`dwindle`.

**The persisted ids are not stable.** Across a reboot two named workspaces
traded ids: `-1337` and `-1340` swapped between monitors. If these rules ever
did match, a reboot would apply one monitor's saved layout to the other.

### Steps to reproduce

1. Focus a named workspace — a special workspace, or one created with
   `hyprctl dispatch workspace name:foo`.
2. Press `SUPER + L`.
3. The notification reports the new layout, but
   `hyprctl activeworkspace -j | jq -r .tiledLayout` is unchanged.
4. Press it again. It reports the same layout again, never the other one.

### Expected behavior

The layout changes, and repeated presses alternate between `dwindle` and
`scrolling`.

### Related

- #4881 reports the same root cause for special workspaces, open since March,
  and reaches the same conclusion: identify the workspace by name, not id.
- PR #4880 implemented exactly that and was closed in favour of #5099, which is
  still open and unmerged.
- #7612 documents the same `<id>.lua` persistence from a different angle.

Keying the rule by `name:<workspace name>` fixes all three symptoms and is what
#4880 already proposed. A cheap independent improvement: re-read `.tiledLayout`
after the `eval` and report failure instead of success when it did not change —
the current notification is what makes this hard to diagnose.