### System details

Dell Latitude 7420 (i7-1185G7), eDP-1 1920x1080 @ scale 1.25 (1536x864 logical), Omarchy 4.0.1-1, kernel 7.1.9-arch1-2, foot with `font=JetBrainsMono Nerd Font:size=13`.

### What's wrong?

`Super + Ctrl + T` (Activity) opens btop, and btop refuses to draw: **"Terminal size too small"**.

btop needs at least **80 columns x 24 rows** with the shipped `shown_boxes = "cpu mem net proc"`. I probed the boundary in a detached pty — 80x23 fails, 80x24 passes.

`org.omarchy.btop` is matched by the shared floating-window rule in `default/hypr/apps/system.lua`:

```lua
o.window({ tag = "floating-window" }, { size = { 875, 600 } })
```

875x600 is a fixed pixel size, but btop's requirement is a character grid, so how many cells it buys depends entirely on the terminal font. Measured by launching a real window under the rule and reading `stty size` after the resize settles:

| foot font size | btop gets | Result |
| --- | --- | --- |
| 9 (shipped default) | ~117x33 | fine |
| 13 | **80x24** | passes by exactly one row |
| 14 | ~74x22 | fails on both axes |

So it works at the stock font, which is presumably why it ships this way — but the margin is one row wide, and raising the terminal font by a single point tips it over.

### Why it matters

The failure is opaque: the Activity hotkey opens a window that says only "Terminal size too small", with nothing pointing at the terminal font or the window rule as the cause. Changing your terminal font is ordinary customization, not something a user would connect to a system monitor refusing to start.

`org.omarchy.about` already gets a dedicated size ten lines below, with a comment noting the standard float doesn't fit its layout:

```lua
-- The About fastfetch layout needs more columns than the standard float provides.
o.window("org.omarchy.about", { size = { 920, 480 } })
```

btop has the same problem and a harder failure mode — fastfetch merely wraps badly, btop refuses to render at all.

### Suggested fix

I did not send a PR because the reasonable options are a matter of taste, and one of them turned out not to work:

1. **A bigger dedicated size for btop**, following the `org.omarchy.about` precedent. Note this can only raise the threshold, not remove it. I checked whether an oversized rule would be safe by requesting 3000x2000 on this 1536x864 screen — Hyprland does **not** clamp to the monitor, it really does make a 3000x2000 window. So a size generous enough to help larger fonts (~740 tall) would overflow a 1280x720 logical display, and on such a screen btop at 14pt needs ~98% of the screen height regardless. There is no single pixel size that is right everywhere.
2. **Drop `org.omarchy.btop` from the floating-window class list** so it tiles. Nearly fullscreen on a single-window workspace, no magic numbers, correct at every font size — but it changes Activity from a float to a tile.
3. **Document the interaction** and leave the default alone.

Sizing in character cells would be the actually-correct fix, but Hyprland window rules take pixels.

Locally I am using option 1. A later `size` rule does not override the tag rule, so the tag has to be dropped first:

```lua
o.window("org.omarchy.btop", { tag = "-floating-window" })
o.window("org.omarchy.btop", { float = true })
o.window("org.omarchy.btop", { center = true })
o.window("org.omarchy.btop", { size = { 1100, 740 } })
```

That gives 103x29 at 13pt and clears through 15pt.

Possibly related: #8660 (Super+Ctrl+T opening duplicate Activity windows).