### System details

- Omarchy 4.0.0-1 (Quattro), fresh install on 2026-08-15 (no upgrade history in pacman.log)
- MacBook Pro 2019 (Intel Core i9-9880H, Radeon Pro 5500M, Apple T2) running the linux-t2 kernel
- Norwegian keyboard, selected during installation

### What's wrong?

On a fresh Quattro install where a non-US keyboard layout is chosen in the installer, the Hyprland session comes up with the US layout anyway.

The installer records the choice only as a console keymap:

```conf
# /etc/vconsole.conf
KEYMAP=no-latin1
```

It writes no `XKBLAYOUT`/`XKBVARIANT`. But the packaged Hyprland default derives the session layout exclusively from `XKBLAYOUT`:

```lua
-- /usr/share/omarchy/default/hypr/input.lua
local kb_layout = vconsole.XKBLAYOUT or "us"
local kb_variant = vconsole.XKBVARIANT or ""
```

With only `KEYMAP` present, this silently falls back to `us`, so the console uses Norwegian while the desktop types US/ANSI.

The fcitx5 profile shipped for the compose-key setup is also hardcoded to `keyboard-us` (`~/.config/fcitx5/profile`: `DefaultIM=keyboard-us`), so even after fixing the Hyprland layout, fcitx5's virtual keyboard keeps serving US until its profile is corrected separately.

This is the fresh-install sibling of #6878: that report covers the Quattro *upgrade* dropping the layout when `vconsole.conf` only has `KEYMAP`; here a brand-new install never gets an `XKBLAYOUT` in the first place, so the same `us` fallback triggers.

#### Steps to reproduce

1. Install Omarchy 4.0.0 from scratch and pick a non-US layout (e.g. Norwegian) in the installer.
2. Boot into the installed system and log in to the Hyprland session.
3. Type in any application.

#### Expected behavior

The session uses the layout chosen during installation (here `no`), matching the console keymap.

#### Actual behavior

`hyprctl getoption input:kb_layout` reports `us`; `/etc/vconsole.conf` contains only `KEYMAP=no-latin1` with no `XKBLAYOUT`, so the packaged `input.lua` falls back to `us`. fcitx5 additionally stays on `keyboard-us`.

#### Workaround

```lua
-- ~/.config/hypr/input.lua
hl.config({
  input = {
    kb_layout = "no",
    kb_variant = "mac",
  },
})
```

plus pointing `~/.config/fcitx5/profile` at the matching `keyboard-*` input method (editing it while fcitx5 is stopped, since fcitx5 rewrites the file on exit).

#### Suggested fix

Have the installer write `XKBLAYOUT` (and `XKBVARIANT` where applicable) to `/etc/vconsole.conf` alongside `KEYMAP`, mapping the chosen console keymap to its XKB equivalent (e.g. `no-latin1` → `no`) — or teach `default/hypr/input.lua` to fall back to a `KEYMAP`-derived layout before defaulting to `us`. The fcitx5 profile should follow the same layout instead of a hardcoded `keyboard-us`.