Trust mise configs in the guest so project pins actually apply

[defkode]

Problem

On a fresh sandbox, every project with a mise.toml greets you with:

mise WARN ~/code/tiramizoo/lmm/mise.toml is not trusted, run `mise trust` to enable it

Trust is host-side state and does not survive the mount, so the mounted project's config is untrusted in every new VM.

The warning undersells it. mise doesn't just complain — it skips the config entirely, so the project's pinned Ruby/Node never apply and you silently get whatever the global install provides. And the advice is unactionable where it appears: orbx shell lands you in the project on a machine that exists solely to run it, and agents driving orbx run never see the warning at all.

Fix

Set trusted_config_paths from user-setup.sh:

"$HOME/.local/bin/mise" settings set trusted_config_paths "$HOME" \
  || log "could not set mise trusted_config_paths (expect trust warnings)"

Scoped to $HOME rather than the mount path, which this template does not know. The auto-mount always lands under it (see orbx::mount_target), and a repo cloned inside the sandbox is covered too. What trust gates is code execution from a config file — this is an isolated VM whose entire purpose is executing that project's code, so there is nothing left for the prompt to protect.

Placed alongside ruby.compile, before mise use -g, which already demonstrates that a later use -g preserves settings written earlier into ~/.config/mise/config.toml.

Verification

Tested on a real machine (orbx-trust-test, since deleted), with a scratch project under $HOME carrying a copy of a real project's mise.toml — a plain [tools] table needs no trust, but its [settings.ruby] block does.

Inside the guest:

Check	Result
mise settings get trusted_config_paths	["/home/tomasz"]
mise trust --show in the project dir	~/code/orbx-trust-test: trusted
~/.config/mise/config.toml	[settings] and [tools] both intact

A/B in the same VM:

• Trust neutralised (pre-fix): mise WARN ~/code/orbx-trust-test/mise.toml is not trusted, run 'mise trust' to enable it — reproduces verbatim.
• As provisioned (post-fix): that warning is gone, replaced by mise WARN missing: node@24.16.0 ruby@4.0.5.

That second message is the real proof: mise is now reading the config and reporting its pinned tools aren't installed. Before, it never even knew those versions were requested.

shellcheck clean; 89/89 bats pass (88 + the new template test).

Known gap

A project living outside the host's $HOME keeps its absolute path in the guest (orbx::mount_target rewrites nothing there) and so falls outside the trusted path. The guest makes a general fix easy if we want it — /proc/mounts lists the share as mac /home/tomasz/code/orbx-trust-test virtiofs, so provisioning could trust every virtiofs mountpoint instead.

Follow-up worth a decision

The now-visible missing: node@24.16.0 ruby@4.0.5 is arguably correct behaviour. Provisioning installs ruby@latest/node@lts globally, not the project's pins; running mise install in the project dir during provisioning would resolve it, but it is slower and can fail on versions with no prebuilt binary. Left alone here.