### Summary

`omarchy-update -y` hangs indefinitely at the orphan-package step whenever stdin/stdout are TTYs. `omarchy-update-orphan-pkgs` decides interactivity purely from `-t 0`/`-t 1` and never consults `-y` or `OMARCHY_UPDATE_UNATTENDED`, so it calls `gum confirm` in a run that promised not to ask anything.

### Current behaviour

```bash
# /usr/share/omarchy/bin/omarchy-update-orphan-pkgs
if [[ ! -t 0 || ! -t 1 ]]; then
  echo "${#orphans[@]} orphaned package(s) found. Re-run omarchy-update-orphan-pkgs in a terminal to review/remove them."
  echo
  exit 0
fi

if ! gum confirm --default=false "Remove ${#orphans[@]} orphaned package(s)?"; then
```

The TTY check is a reasonable proxy for "nobody is watching", but it is the wrong signal here. `omarchy-update` itself documents the contract:

```bash
# -y is a promise not to ask anything. Steps that would need an answer report
# and move on instead of waiting on a prompt nobody is here to give.
[[ ${1:-} != "-y" ]] || export OMARCHY_UPDATE_UNATTENDED=1
```

`omarchy-update-orphan-pkgs` is the one step that ignores it. Note also that `omarchy-update` re-execs itself under `script -qefc`, which allocates a PTY — so stdin/stdout are TTYs even in contexts where no human is present.

### Reproduction

1. Have at least one orphan (`pacman -Qtdq` non-empty). Mine were `asar` and `vulkan-headers`, pulled in as build deps by `quickshell-git`.
2. Run `omarchy-update -y` attached to a PTY but with no human answering (automation, supervised process, CI, agent-driven session).
3. Output stops after the orphan list and never advances.

```
Orphan system packages
  asar
  vulkan-headers

<hangs here>
```

I left it 27 minutes. `gum` never rendered its TUI over that PTY; keystrokes sent to the process were echoed back as raw text rather than consumed, so the prompt could not be answered from outside either. I had to `SIGTERM` it.

### Consequence

Everything after the orphan step is skipped:

```bash
omarchy-update-orphan-pkgs      # blocks here
omarchy-update-analyze-logs
omarchy-update-status
omarchy-update-restart
```

The update's own log analysis, status report, and reboot offer never run, and the caller sees a hang rather than a failure. The package transaction itself had already completed successfully, so the system is in a fine state — but an automated caller cannot tell.

### Suggested fix

Honour the existing contract:

```bash
if [[ ${OMARCHY_UPDATE_UNATTENDED:-0} == 1 || ! -t 0 || ! -t 1 ]]; then
  echo "${#orphans[@]} orphaned package(s) found. Re-run omarchy-update-orphan-pkgs in a terminal to review/remove them."
  echo
  exit 0
fi
```

That keeps interactive behaviour unchanged and makes `-y` mean what the parent script says it means. Any other step calling `gum` should get the same treatment.

### Environment

```
Omarchy  4.0.4
invoked  omarchy-update -y  (as root, PTY attached)
orphans  asar, vulkan-headers
```