### System details

AMD Ryzen 7 9700X, NVIDIA RTX 5070 + AMD Granite Ridge iGPU, Omarchy 4.0.0-1, Chromium 151.0.7922.173-1 (Arch)

### What's wrong?

Follow-up to #6816 (stale `extensions.commands` registration pointing at a path-derived extension ID), which shipped `migrations/1786643346.sh` as the repair. On this machine the repair never applied, and when I ran it by hand it did not persist. Two separate problems, both leaving `Alt+Shift+L` dead with no indication anything is wrong.

**1. Fresh installs stamp the migration complete, so it never runs**

`install/user/first-run/audio-tuning.sh` documents the behavior: *"the finalizer marks all shipped migrations complete on a fresh install."* That is reasonable for a genuinely new profile, but the Chromium profile is not part of the Omarchy install — it commonly arrives afterwards from sync or a restored `~/.config/chromium`, carrying the pre-pinned-ID `extensions.commands` registration with it.

On this machine:

- Omarchy installed 2026-08-23; the copy-url extension first loaded 2026-08-23 04:13 (`first_install_time` in `extensions.settings`).
- Both `~/.local/state/omarchy/migrations/1784763917.sh` and `1786643346.sh` are stamped `2026-08-23 11:10:46` — the same second, i.e. bulk stamping, not two real runs.
- No `Preferences.omarchy-copy-url-repair.bak` existed, confirming the repair had never executed.
- `Alt+Shift+L` was registered to `agnpjekbinplibibdbochbceckhennie` while the loaded extension was the pinned `bgpiichlckmfanooecilcjemknkcpngb`.

So exactly the class of profile the migration exists for is the class that never gets it. A migration whose subject is browser profile state rather than Omarchy's own config can't be satisfied by install-time stamping.

**2. The `Preferences` edit did not survive the next browser start**

Running the migration by hand, with every Chromium process gone and the profile's `Singleton*` files removed:

```
08:50  bash /usr/share/omarchy/migrations/1786643346.sh
       → Preferences.omarchy-copy-url-repair.bak written
       → verified on disk: linux:Alt+Shift+L -> bgpiichlckmfanooecilcjemknkcpngb (pinned)
       → ghost absent from extensions.settings
~08:52 launched the web apps
08:56  Preferences rewritten: linux:Alt+Shift+L -> agnpjekbinplibibdbochbceckhennie
```

No browser was running during the repair, and I verified the repaired content before any browser started, so this is not the "browser open during repair" case the script already guards against.

What the ghost looks like now in `Default/Preferences`:

```
/extensions/settings/agnpjekbinplibibdbochbceckhennie                        = {}
/protection/macs/extensions/settings/agnpjekbinplibibdbochbceckhennie        = 3D7E1BF0...
/protection/macs/extensions/settings_encrypted_hash/agnpjek...               = djEx03I0...
```

An empty settings dict with live MAC entries looks like Chromium's protected-preference enforcement reasserting a pref that was modified out of band — `extensions.settings` is MAC'd under `protection/macs`, and the migration deletes entries there (`settings.pop(ghost, None)`) without any way to recompute the HMAC. This profile is also signed in with `extensions` among its sync types, which is a second candidate for the restore. I have not isolated which of the two did it; either way the conclusion is the same: an external edit to `Preferences` is not a reliable way to release the accelerator, and the script's own verification pass can report success while the change is reverted minutes later.

**What actually fixed it**

Assigning the shortcut in `chrome://extensions/shortcuts` from the browser UI. That has held across restarts — Chromium recomputes the MACs itself and the mapping now points at the pinned ID.

### Steps to reproduce

1. Have a Chromium profile that registered `Alt+Shift+L` under a path-derived copy-url ID (see #6816), signed in with sync enabled.
2. Install Omarchy fresh, then sign into Chromium so the profile is restored. Migration `1786643346` is already stamped complete, so it never runs and `Alt+Shift+L` does nothing.
3. Run `bash /usr/share/omarchy/migrations/1786643346.sh` by hand with all browsers closed. It reports success and writes the `.bak`.
4. Start Chromium, use it for a few minutes, then re-read `Default/Preferences`: the accelerator points at the ghost ID again.

### Expected

`Alt+Shift+L` copies the current URL on a machine where Omarchy loaded the extension and registered the native-messaging host — including when the Chromium profile predates or postdates the Omarchy install.

### Suggested direction

- Don't settle this from outside the browser. Chromium owns `extensions.commands` and MACs the surrounding prefs; an unpacked extension whose suggested key is taken could surface the conflict in-product (e.g. the extension notices `chrome.commands.getAll()` returns no shortcut for `copy-url` and points the user at `chrome://extensions/shortcuts`), which needs no privileged file editing and can't be silently reverted.
- If the file-level repair stays, it should verify after a browser restart rather than immediately after writing, and it should not be eligible for install-time stamping — browser-profile state isn't established at install time.
- Relatedly, #7019's "browser window is open" with no browser running reproduced here: `profile_open()` treats a dangling `SingletonLock` symlink as an attached browser, and a Chromium killed with SIGTERM leaves that symlink behind pointing at a dead PID. Resolving the symlink target's PID (or checking the socket) would tell a stale lock from a live one.

Diagnostics available on request — happy to test a patch on an affected profile.