## Description

`bin/omarchy-remove-security-sshd` resolves the keys file as `AUTHORIZED_KEYS="$HOME/.ssh/authorized_keys"`. The script is marked `omarchy:requires-sudo=true`, and under `sudo` (or `pkexec`, the escalation `default/agents/skills/omarchy/SKILL.md` prescribes for terminal-less callers) `$HOME` is `/root` — so the script inspects and offers to delete **root's** `authorized_keys`, not the invoking user's.

## Impact

The command's stated contract is "Disable the OpenSSH server, close the firewall port, and optionally remove authorized keys". Under escalation:

- Root usually has no `authorized_keys`, so `[[ -s $AUTHORIZED_KEYS ]]` is false and the removal prompt is silently skipped. The invoking user's real `~/.ssh/authorized_keys` survives, and those keys are live again the moment sshd is re-enabled — while the operator believes SSH access was fully torn down.
- If root *does* have an `authorized_keys`, the prompt targets and deletes root's keys instead of the user's.

This is the same `$HOME`-under-escalation class as #9569, but split out because here it changes a security decision rather than leaving cache data behind (related hardening context: #9267, #9255).

## Root cause

```bash
AUTHORIZED_KEYS="$HOME/.ssh/authorized_keys"
```

with no derivation of the invoking user, unlike sibling privileged scripts (`omarchy-apply-lock` derives `OMARCHY_INSTALL_USER` → `SUDO_USER` → `PKEXEC_UID`).

## Suggested fix

Apply the `omarchy-apply-lock` target-user derivation and point `AUTHORIZED_KEYS` at that user's home. PR incoming.

Environment: observed against `quattro` @ 2de641b-era checkout (current tip), script unchanged on `omacom/omarchy` HEAD.