`bin/omarchy-capture-screenrecording` keeps the path of the recording in flight at a fixed name in `/tmp`:

```bash
RECORDING_FILE="/tmp/omarchy-screenrecord-filename"
REGION_FILE="${XDG_RUNTIME_DIR:-/tmp}/omarchy-screenrecord-region"
```

The line below it already uses the per-user runtime directory. This one does not.

`/tmp` is world-writable — the sticky bit prevents deleting another user's file, not creating the name first — and the contents of that file are read back on stop and used as a **filesystem path**:

```bash
finalize_recording() {
  latest=$(cat "$RECORDING_FILE" 2>/dev/null)
  [[ -f $latest ]] || return
  ...
  local processed="${latest%.mp4}-processed.mp4"
  if ffmpeg "${args[@]}" "$processed" -loglevel quiet 2>/dev/null; then
    mv "$processed" "$latest"
  ...
}

stop_screenrecording() {
  ...
  local filename=$(cat "$RECORDING_FILE" 2>/dev/null)
  local preview="${filename%.mp4}-preview.png"
  ffmpeg -y -i "$filename" ... "$preview" ...
  omarchy-notification-send "Screen recording saved" ... --exec mpv -- "$filename"
  rm -f "$preview"
}
```

So another local account that owns the name controls, as the recording user:

- where `ffmpeg -y` writes (`<path>-processed.mp4`, `<path>-preview.png` — `-y` overwrites without asking)
- what `mv` replaces (`<path>` itself)
- what `rm -f` deletes
- the path the "Screen recording saved" toast opens in mpv when clicked

`[[ -f $latest ]]` only checks that the target exists, which is exactly the case for a file worth clobbering. `$XDG_RUNTIME_DIR` is 0700 and per-user, so the sibling region file has none of this.

`OMARCHY_SCREENRECORD_DEBUG=true` has the same shape: it appends the recorder's stderr and the picked geometry to `/tmp/omarchy-screenrecord.log`.

Same class as #7904 (FIDO2 authfile staged at a predictable `/tmp` path).

## Expected

Keep the recording state and the debug log beside the region file under `$XDG_RUNTIME_DIR`.