fix: forward Launchable base image

[sandl99]

What

Forward createWorkspaceRequest.imageId from a Launchable response to the
workspace creation request as baseImage.

The regression coverage now checks both the populated
CreateWorkspacesOptions.BaseImage field and the serialized baseImage JSON
field.

Why

LaunchableWorkspaceRequest already deserializes the API's imageId, but
applyLaunchableWorkspaceRequest did not copy it into
CreateWorkspacesOptions.BaseImage. As a result, brev create --launchable
silently dropped a Launchable's custom VM image and the workspace could boot
from the default image instead.

This surfaced in the NemoClaw staging E2E when the workspace created
successfully but did not contain the image-baked
/etc/nemoclaw/provision.json receipt:

• Failed workflow run
• Failed job
• Successful staging-image producer run

Validation

• gofmt -d pkg/cmd/gpucreate/gpucreate.go pkg/cmd/gpucreate/gpucreate_test.go
• go test ./pkg/cmd/gpucreate

Both ran with Go 1.25.

Manual follow-up after merge

This client fix is necessary but is not sufficient for the current NemoClaw
Launchable because its stored createWorkspaceRequest does not currently
contain an imageId.

1. Release a Brev CLI version containing this change.

2. In the Brev Console or Launchables API, create or update the standing
   NemoClaw staging Launchable so its createWorkspaceRequest.imageId is:

   projects/brevdevprod/global/images/family/nemoclaw-brev-staging-cpu
   

3. Confirm through the Launchable configuration/API response that imageId
   is present. brev create --dry-run does not currently expose the selected
   image, so it is not sufficient for this check.

4. Create a disposable workspace using the new CLI release and Launchable.
   Verify:

   • /etc/nemoclaw/provision.json exists.
   • /opt/nemoclaw-image/NemoClaw exists.
   • The provision receipt identifies the expected image/source revision.
   • The workspace is deleted after validation.

5. Update the NemoClaw workflow's pinned Brev CLI version and SHA-256 checksum
   to the release containing this fix.

6. Manually update the NemoClaw repository variable
   NEMOCLAW_STAGING_LAUNCHABLE_ID only after the replacement Launchable has
   passed the probe above.

7. Dispatch the trusted full NemoClaw E2E and verify provisioning, checkout,
   test, and cleanup evidence.

This PR intentionally does not change NEMOCLAW_STAGING_LAUNCHABLE_ID.

[jyaunches]

Additional NemoClaw E2E evidence confirms this is the active failure mode for the same standing Launchable, env-3GdbIjswX4fs3VJ6cYRHr5zoQXo.

• Consumer: https://github.com/NVIDIA/NemoClaw/actions/runs/30593860691 (job https://github.com/NVIDIA/NemoClaw/actions/runs/30593860691/job/91041963022)
• Producer: https://github.com/brevdev/nemoclaw-image/actions/runs/30593923814
• Producer published and re-resolved projects/brevdevprod/global/images/family/nemoclaw-brev-staging-cpu to exact image nemoclaw-brev-cpu-v0-1-0-20260731-0030ba4d3-staging-7-1, numeric image ID 2448552564900645250, status READY.
• Five minutes after the producer handoff, Brev CLI v0.6.331 deployed the standing Launchable as n2d-standard-4, VM mode, 256 GiB. Workspace svjws2gpw became ready.
• Guest GCE metadata reported the actual boot image as projects/ubuntu-os-accelerator-images/global/images/ubuntu-accelerator-2204-amd64-with-nvidia-580-v20260724, not a stale member of the NemoClaw family.
• The exact guest-image check failed closed and cleanup verified the workspace absent.

The v0.6.331 source trace matches this PR's root cause exactly: LaunchableWorkspaceRequest deserializes imageId, but applyLaunchableWorkspaceRequest does not assign it to CreateWorkspacesOptions.BaseImage. Therefore the workspace create request omits baseImage, and the observed stock image is consistent with server-side default selection. There is no evidence that Brev evaluated and rejected the NemoClaw image for compatibility; the client never forwarded it.

This PR remains necessary, and its documented Launchable repair remains separately necessary because the standing Launchable's stored request lacks imageId. A safe retry should wait for all of the following:

1. Merge and release this fix, then pin the NemoClaw E2E to that Brev CLI release and checksum.
2. Repair or replace the standing Launchable so its API/config response contains createWorkspaceRequest.imageId = projects/brevdevprod/global/images/family/nemoclaw-brev-staging-cpu (the description alone is not evidence).
3. Probe one disposable workspace and require the expected GCE guest image identity plus /etc/nemoclaw/provision.json; delete it afterward.
4. Only then retry the trusted Launchable E2E. Keep the exact producer-handoff/guest-metadata comparison unchanged and do not add another delay.

The family has advanced since the cited failure: the latest successful producer handoff visible at the time of this comment is run https://github.com/brevdev/nemoclaw-image/actions/runs/30628382825, exact image nemoclaw-brev-cpu-v0-1-0-20260731-6ff018521-staging-9-1, ID 4944077805399911091. A retry should use a fresh correlated producer handoff rather than the older image above.