No way to run a command on a VM, so anything outside sync/build/compose falls back to raw ssh

There is no way to run a command on a VM in the fleet. Everything BaryoVM does is sync, build, compose or backup, so the moment a task falls outside that shape you drop back to raw `ssh -i ~/.ssh/key user@host`, which is the thing the tool exists to replace. ## How this came up Deploying baryo.dev (#22). Three things needed doing on the VM that had nothing to do with containers: read a config file to check what was deployed, restore an SELinux context, and reload nginx. The last two got solved properly by adding `postDeploy` to the release manifest, which is the right answer for anything that is part of a release. The first one had no answer. Checking the state of a machine is not a release step, and there is no command for it. The same gap turns up whenever you want to answer a question rather than change something: what is in this env file, is this port listening, how much disk is left, what does this log say right now. `vm ping` reports host and Docker version and stops there. ## Why this is small The plumbing already exists. `internal/sshx` has: ```go func Dial(t Target) (*Client, error) func (c *Client) Run(cmd string) (string, error) func Quote(s string) string ``` `stack release` already uses `c.Run(...)` to build images and now to run `postDeploy`. This is exposing what is already there as a command, not building new infrastructure. ## Shape ```sh baryovm vm exec oracle -- systemctl status nginx baryovm vm exec oracle -- 'df -h /var/www' baryovm vm exec oracle --sudo -- nginx -t baryovm vm exec oracle -o json -- 'cat /etc/os-release' ``` Worth deciding in the issue rather than in review: **Does it take a `--sudo` flag, or is that the caller's business?** `sudo -n` inside the quoted command works today and needs nothing from the CLI. A flag is friendlier but adds a way to get it wrong. Leaning towards no flag. **What does `-o json` return?** At minimum stdout, stderr and the exit code as separate fields, because the whole point of the JSON mode is that the MAUI app and MCP server consume it. Merging the two streams the way the human output does would make it useless for that. **Does a non-zero exit from the remote command fail the CLI?** It should, and the exit code should propagate, otherwise `baryovm vm exec ... && something-else` silently does the wrong thing. **Multiple VMs?** `--all` or a fleet-wide form is the obvious next ask, and worth deliberately not building yet. Running an arbitrary command across a whole fleet is a different risk from running it on one named machine. ## Security This is not new authority. It runs as the SSH user with the key already in `fleet.json`, so anyone who can run this could already have opened an SSH session. It does make that authority one word shorter, which is worth stating plainly in the help text rather than leaving implied. `SECURITY.md` should get a line, since "the CLI can run arbitrary commands on your fleet" is a fair thing for someone evaluating the tool to want stated out loud. ## Tests The command builder is the testable part: quoting, `--` handling, and that a remote non-zero exit becomes a non-zero exit here. Actual SSH is not worth mocking.