docs: fix invalid devsy up command refs

sites/docs-devsy-sh/content/docs/developing-in-workspaces/continuous-integration.mdx

@@ -12,7 +12,7 @@ still builds.
 ### How it works
 
 1. Resolves a workspace from the current directory (or a given source).
-2. Builds and starts the devcontainer (equivalent to `devsy up`, without
+2. Builds and starts the devcontainer (equivalent to `devsy workspace up`, without
    launching an IDE or touching your SSH config).
 3. Runs the given command inside the running container.
 4. Deletes the workspace — always, even when the command fails — unless

sites/docs-devsy-sh/content/docs/developing-in-workspaces/workspace-snapshots.mdx

@@ -13,7 +13,7 @@ Snapshots are pushed to and pulled from an OCI registry (Docker Hub, GHCR, ECR,
 
 ## Create a Snapshot
 
-The workspace must already be running (`devsy up` must have created it, so its mount information is available):
+The workspace must already be running (`devsy workspace up` must have created it, so its mount information is available):
 
 ```sh
 devsy snapshot create my-workspace --registry ghcr.io/my-org/snapshots
@@ -60,10 +60,10 @@ devsy snapshot restore ghcr.io/my-org/snapshots:my-workspace-20260731150405-x7f2
 
 This creates a new workspace from the snapshot's committed filesystem and volumes, skipping the devcontainer build entirely since the image is already built. By default the new workspace reuses the original workspace ID; pass `--workspace-id` to restore under a different one, or `--target-provider` to restore using a different provider than the one the snapshot was taken from.
 
-Equivalently, you can restore as part of `devsy up`:
+Equivalently, you can restore as part of `devsy workspace up`:
 
 ```sh
-devsy up --from-snapshot ghcr.io/my-org/snapshots:my-workspace-20260731150405-x7f2qk
+devsy workspace up --from-snapshot ghcr.io/my-org/snapshots:my-workspace-20260731150405-x7f2qk
 ```
 
 `--from-snapshot` can't be combined with a positional source or `--source`.

sites/docs-devsy-sh/content/docs/how-it-works/deploying-workspaces.mdx

@@ -21,7 +21,7 @@ the local `container` CLI for Apple, its own sandbox client for Microsandbox) to
 users then optionally retrieves credentials from the local environment before launching the IDE. Once the IDE has started the deployment process has complete, Devsy's agent daemon will continue to monitor the
 workspace to put the machine or container to sleep when not in use.
 
-Alternatively, `devsy up --from-snapshot <ref>` skips this build-and-deploy flow entirely: it restores a previously saved [workspace snapshot](../developing-in-workspaces/workspace-snapshots.mdx)'s container
+Alternatively, `devsy workspace up --from-snapshot <ref>` skips this build-and-deploy flow entirely: it restores a previously saved [workspace snapshot](../developing-in-workspaces/workspace-snapshots.mdx)'s container
 filesystem and volumes directly, so no devcontainer build is needed.
 
 ## Connecting to machines

sites/docs-devsy-sh/content/docs/how-it-works/overview.mdx

@@ -25,4 +25,4 @@ The tunnel's transport depends on the provider — AWS uses Instance Connect, Ku
 
 Port forwarding requires an active IDE or SSH session — Devsy needs the agent's SSH server, which only runs while one of those connections is open.
 
-Instead of building from a devcontainer each time, you can also create a workspace from a previously saved [workspace snapshot](../developing-in-workspaces/workspace-snapshots.mdx) with `devsy up --from-snapshot`, which restores the container filesystem and volumes directly and skips the build step entirely.
+Instead of building from a devcontainer each time, you can also create a workspace from a previously saved [workspace snapshot](../developing-in-workspaces/workspace-snapshots.mdx) with `devsy workspace up --from-snapshot`, which restores the container filesystem and volumes directly and skips the build step entirely.