### System details

source review against omacom/omarchy master; keymap behaviour reproduced on Arch with systemd 261 and kbd 2.10.0

### What's wrong?

`install/provisioning/setup-form.sh` offers two keyboard layouts whose console keymaps belong to entirely different languages:

```
Azerbaijani|azerty          # line 36
Lao|la-latin1               # line 61
```

- `azerty` is the generic **French** console keymap. `kbd` ships it at `keymaps/i386/azerty/azerty.map.gz`, in the same directory as `fr-latin1`, `fr-afnor`, `fr.map.gz` and `be-latin1`. There is no Azerbaijani keymap in `kbd` at all.
- `la-latin1` is **Latin American Spanish** — `kbd` ships it under `keymaps/i386/qwerty/`. It is already listed correctly on line 75 as `Spanish (Latin American)|la-latin1`, so the same value appears under two different language names. `la` is the Lao layout code in *xkeyboard-config*, not in `kbd`, which looks like where the mix-up came from.

Both read like name-prefix guesses: "Az…" → `azerty`, "La…" → `la-latin1`.

## Why it matters beyond the label

`apply_keyboard()` in `bin/omarchy-provision-owner` (line 617) runs `systemd-firstboot --keymap="$keymap" --force`, and the ISO does the same with `--root` in `configs/airootfs/usr/share/omarchy-iso/orchestrator/keyboard.py` (line 46). systemd derives `XKBLAYOUT` from `kbd-model-map`, and **`azerty` has no row there**, so no XKB layout is written and `default/hypr/input.lua` line 31 — `local kb_layout = vconsole.XKBLAYOUT or "us"` — falls back to `us`.

So someone who picks "Azerbaijani" in the installer ends up with a French console keymap and a US desktop layout. Neither is Azerbaijani.

The existing guard doesn't catch it: line 621 checks `localectl list-keymaps` before calling firstboot, and `azerty` *is* a real keymap, so it passes — as does `test_all_configurator_keymaps_are_known_to_localectl` in `omarchy-iso`'s `test/unit/test_keyboard.py`. The rows are valid keymaps, just the wrong languages.

## Reproduced

The `systemd-firstboot` behaviour below is reproduced directly; the installer path itself is traced through the source above rather than run from an ISO. systemd 261, kbd 2.10.0, Arch:

```
$ systemd-firstboot --root=$T --keymap=azerty --force
$ cat $T/etc/vconsole.conf
KEYMAP=azerty
$ grep XKBLAYOUT $T/etc/vconsole.conf
$                    # nothing — no XKB layout was written
```

Against a keymap that *is* mapped, for contrast:

```
$ systemd-firstboot --root=$T2 --keymap=trq --force
$ cat $T2/etc/vconsole.conf
KEYMAP=trq
XKBLAYOUT=tr
XKBMODEL=pc105
XKBOPTIONS=terminate:ctrl_alt_bksp
```

And:

```
$ grep -c '^azerty' /usr/share/systemd/kbd-model-map
0
$ ls /usr/share/kbd/keymaps/i386/azerty/
azerty.map.gz  be-latin1.map.gz  fr-afnor.map.gz  fr-latin1.map.gz  fr.map.gz  ...
```

## Possible fixes

1. **Drop both rows.** Accurate — `kbd` has no keymap for either language — but it removes Azerbaijani from the picker rather than making it work.
2. **Let a row carry an explicit XKB layout.** An optional third field in `OMARCHY_KEYBOARD_LAYOUTS` would let Azerbaijani use the closest real console keymap (`trq`, Turkish-Q; Azerbaijani Latin shares its letters apart from `ə`) while setting `XKBLAYOUT=az`, which *xkeyboard-config* does support. That gives a correct Wayland layout where the console can't express one. It changes the pipe format, so `omarchy-iso`'s `test_keyboard.py` (line 34, `line.split("|", 1)[1]`) would need a companion PR.

Either way `Lao|la-latin1` should go, since it duplicates the Spanish row.

Happy to send a PR for whichever direction you prefer.