### System details

- **Omarchy:** 4.0.1-1
- **Hyprland:** 0.56.2
- **Kernel:** 7.1.9-arch1-2
- **CPU:** Intel Core i9-9980HK
- **GPU:** Virtio 1.0 GPU
- **Platform:** Parallels Virtual Platform (VM guest, macOS host)
- **Keyboard:** `at-translated-set-2-keyboard` (internal, via Parallels)

### What's wrong?

The default `repeat_delay = 250` in `default/hypr/input.lua` causes duplicated
characters during ordinary typing on this system. Normal typing produces output
like `helllo` / `commmand` several times per paragraph.

#5293 set this value, stating: *"In my testing, this is the lowest you can go
without causing any issues with double key presses."* This report is a
counter-example to that premise — at 250ms, ordinary keystroke dwell time
crosses the repeat threshold, and `repeat_rate = 40` then emits a burst rather
than a single extra character, so each trip is very visible.

**Caveat, stated up front:** this is a Parallels VM guest. Keystroke timing
passes through the hypervisor and may jitter more than on bare metal, so this
may be specific to virtualized guests rather than universal. I have not been
able to test the same config on bare metal. Flagging it because Omarchy in a
Parallels/UTM VM is a common way to evaluate the distro, and the current default
makes typing unreliable there out of the box.

### Steps to reproduce

1. Install Omarchy 4.0.1 in a Parallels VM (defaults, no input customization).
2. Type normal prose in any application.
3. Observe duplicated letters at a rate of roughly a few per paragraph.

### Expected

Default settings should not produce duplicated characters during normal typing.

### Workaround

Raising the delay in `~/.config/hypr/input.lua` fixes it completely:

```lua
hl.config({
  input = {
    repeat_delay = 600,
    repeat_rate = 30,
  },
})
```

`repeat_delay` is the significant one; 500 improved things noticeably and 600
eliminated the duplication entirely.

### Suggestion

The tradeoff in #5293 is real — a long delay does make held-key deletion and vim
motions feel sluggish. But the two goals are separable: `repeat_delay` controls
how easily repeat is triggered accidentally, while `repeat_rate` controls how
fast it goes once deliberately triggered. Raising the delay toward 400-500 while
keeping the rate high would preserve most of the fast-hold benefit that #5293
wanted, with a much smaller accidental-trigger window.