### Summary

All three bundled Chromium extensions (`copy-url`, `yt-dlp`, `whatsapp-slim`) silently fail to load in **Google Chrome 153**, because Chrome no longer honours the `--load-extension` command-line flag that Omarchy uses to install them.

They still load correctly in **Chromium 152**, so this is specific to newer Chrome (and presumably other Chromium-family builds as they catch up).

There is no error and no warning — `~/.config/chrome-flags.conf` still contains a correct-looking `--load-extension=` line, the native messaging hosts are installed and working, and the keyboard shortcuts are still advertised in the Omarchy keybindings menu (`SUPER + K`). The features just do nothing.

### What breaks

| Extension | User-facing feature | Status on Chrome 153 |
|---|---|---|
| `copy-url` | `Alt+Shift+L` — copy tab URL to clipboard + notification | dead |
| `yt-dlp` | `Alt+Shift+D` — download page video to `~/Videos` | dead |
| `whatsapp-slim` | system theme + collapsed chat rail on web.whatsapp.com | dead |

Omarchy owns this config for Chrome, so this is not user misconfiguration:

- `omarchy-install-browser chrome` runs `copy_chromium_flags ~/.config/chrome-flags.conf`
- migration `1785543725.sh` explicitly appends `whatsapp-slim` to `$HOME/.config/chrome-flags.conf`

The same `copy_chromium_flags` path is used for Edge and Brave, so those are likely affected too once their Chromium base crosses the same version.

### Steps to reproduce

Minimal, self-contained — a trivial extension that stamps an attribute on any page:

```bash
mkdir -p /tmp/lt/ext /tmp/lt/www
cat > /tmp/lt/ext/manifest.json <<'JSON'
{ "manifest_version": 3, "name": "loadtest", "version": "1.0",
  "content_scripts": [{ "matches": ["http://localhost:8811/*"],
                        "js": ["mark.js"], "run_at": "document_end" }] }
JSON
echo "document.documentElement.setAttribute('data-ext-loaded','YES');" > /tmp/lt/ext/mark.js
echo '<!doctype html><title>t</title><body>hello' > /tmp/lt/www/index.html
(cd /tmp/lt/www && python3 -m http.server 8811 &) ; sleep 2

for br in google-chrome-stable chromium; do
  rm -rf /tmp/lt/p
  timeout 30 $br --headless=new --no-sandbox --user-data-dir=/tmp/lt/p \
    --load-extension=/tmp/lt/ext --virtual-time-budget=4000 \
    --dump-dom http://localhost:8811/ 2>/dev/null > /tmp/lt/o.html
  echo "$br -> page_ok=$(grep -c hello /tmp/lt/o.html) ext_loaded=$(grep -c data-ext-loaded /tmp/lt/o.html)"
done
```

Result:

```
google-chrome-stable -> page_ok=1 ext_loaded=0     # flag ignored
chromium             -> page_ok=1 ext_loaded=1     # works
```

`page_ok=1` in both confirms the page itself loaded, so the failure is the extension, not the harness.

Adding `--enable-unsafe-extension-debugging` or `--disable-extensions-except=<dir>` does not change the Chrome result.

### Also confirmed headful

Not just a headless artefact. On a real desktop Chrome 153 session:

1. A custom unpacked extension added to the `--load-extension=` list in `~/.config/chrome-flags.conf`, followed by a full Chrome restart → its CSS had **no effect** (verified via `getComputedStyle` on a live page; the flag was present in `/proc` cmdline).
2. The **same extension, same files**, installed via `chrome://extensions` → **Load unpacked** → worked immediately.

Only the delivery mechanism differed.

Correspondingly, `Alt+Shift+L` and `Alt+Shift+D` do nothing on Chrome 153, and Hyprland is not intercepting them (no `ALT+SHIFT` binds on `L`/`D` — checked via `hyprctl binds`).

### Suggested fix

Chrome removed `--load-extension` as an anti-malware measure, so it is unlikely to come back. The supported replacement for machine-provisioned extensions is enterprise policy — which Omarchy already has plumbing for, since `browser-policy.sh` provisions `/etc/opt/chrome/policies/managed` (currently holding `color.json`).

Delivering the three extensions via an `ExtensionSettings` policy entry (packed `.crx` + `update_url`, or `installation_mode: normal_installed`) would keep them working across the whole Chromium family without relying on the removed flag.

Failing that, it would at least help to detect the situation and warn the user, rather than leaving three advertised keybindings silently doing nothing.

### System details

```
Omarchy        4.0.3-1  (BUILD_ID 4.0.3)
Kernel         7.2.3-arch1-3
Hyprland       0.56.2
google-chrome  153.0.8010.36-1   <- broken
chromium       152.0.7977.82-1   <- works
```

Native messaging hosts are installed correctly and are not the problem —
`com.omarchy.copy_url` and `com.omarchy.ytdlp` are both registered under
`~/.config/google-chrome/NativeMessagingHosts/` and point at valid host scripts.