### System details

Intel i5-9400H, UHD Graphics 630, Omarchy 4.0.2-1

### What's wrong?

ISO / first-boot Node setup writes an **exact** mise pin. Network / runtime setup writes `latest`. `omarchy update` then runs `mise up` (not `--bump`), so those two cohorts never converge. ISO users also diverge from each other across ISO ages, because each image pins whatever tarball it shipped.

This is not a local breakage — Node 26.7.0 works — but it is a user-to-user version mismatch that `omarchy update` does not heal.

**What I see on an ISO install**

`~/.config/mise/config.toml`:

```toml
[tools]
codex = "latest"
gh = "latest"
go = "latest"
node = "26.7.0"
"npm:@xai-official/grok" = "latest"
"npm:playwright" = "latest"
opencode = "latest"
```

`mise ls --current node`:

```
node  26.7.0  ~/.config/mise/config.toml  26.7.0
```

After `omarchy update` / `mise up`, mise reports:

```
mise Newer versions are available but do not match the configured version ranges:
  node 26.7.0 → 26.8.1 (~/.config/mise/config.toml)
Run `mise outdated --bump` to view all, or `mise upgrade --bump` to update the configuration and upgrade.
```

Other mise tools on the same machine *are* `latest` and do move. Node is the exception because it came from the bundled tarball.

**Why**

`install/user/mise-work.sh`:

- ISO / `provision-owner` with a bundled tarball: `mise use -g node@"$NODE_VERSION"` (exact pin, so the offline unpack is selected).
- Any other run, or missing tarball fallback: `mise use -g node@latest`.

`bin/omarchy-update-mise` (and the `mup` alias) then does:

```bash
MISE_MINIMUM_RELEASE_AGE=0 mise up
```

That respects the configured range. An exact pin stays frozen. `latest` keeps moving. There is no migration that retargets the ISO pin once the machine is online.

That sits oddly next to the comment on `omarchy-update-mise` that running `omarchy update` is the user asking for current versions now. Node from the ISO path is excluded from that.

**Expected**

After a normal `omarchy update`, ISO-installed Node should follow the same policy as the network path (and as `gh` / `go` / the other mise tools), so users do not stay split by install method or ISO vintage.

Pinning the bundled tarball for *offline first boot* is reasonable. Leaving that exact pin in `~/.config/mise/config.toml` forever is what creates the split.

**Not asking users to run** `mise upgrade --bump`. That is mise's generic hint, not an Omarchy command. Omarchy never calls `--bump`.