move VMM types from omicron-common to sled-agent-types-versions

[hawkw]

As described in #10290, the types in the sled-agent API that represent VMM states are currently defined in the omicron-common crate, rather than sled-agent-types-versions. This is problematic, as it is essentially equivalent to saying that these types can never be changed. The reason for this (also described in #10290) is that these types presently appear in both the sled-agent API and the nexus-internal API, the latter of which is client-side versioned. The appearance of these types in the client-side-versioned API is an issue, as they cannot easily be changed, since client-side versioned APIs are not currently handled by the API versioning tools.

Thus, #10290 proposes that we decouple this mess by removing cpapi_instances_put, the nexus-internal API that currently uses the types also appearing in the sled-agent API. To do this, we must first move these types into the sled-agent-types-versions crate so that they can participate in versioning. This PR does that. Most code which references these types now gets them from sled-agent-types. The exception is the Nexus-Internal API itself, which, as previously mentioned, is client-side versioned, and must explicitly depend on the v1 version of SledVmmState forever (which, again, is why we are gonna get rid of it entirely).

I did not make the behavioral change described in #10290 (where Nexus would ignore the SledVmmState body sent to cpapi_instances_put and instead treat it as the doorbell API that will eventually replace it). Since this PR ends up touching so many files just to rename the types, I didn't want to make the behavioral changes here, or add the new nexus-internal version, because I think those deserve to be separate commits. These will come later.

[hawkw]

Uh, hmm. It looks like a whole bunch of stuff has gone wrong with this helios / deploy run, beginning with a zpool create failing:

179	2026-04-21T20:34:44.154Z	+ pfexec zpool create -f scratch c1t1d0 c2t1d0
180	2026-04-21T20:34:44.178Z	cannot open 'c2t1d0': no such device in /dev/dsk
181	2026-04-21T20:34:44.178Z	must be a full path or shorthand device name
182	2026-04-21T20:34:44.179Z	+ _exit_trap

[hawkw]

Uh, hmm. It looks like a whole bunch of stuff has gone wrong with this helios / deploy run, beginning with a zpool create failing:

179	2026-04-21T20:34:44.154Z	+ pfexec zpool create -f scratch c1t1d0 c2t1d0
180	2026-04-21T20:34:44.178Z	cannot open 'c2t1d0': no such device in /dev/dsk
181	2026-04-21T20:34:44.178Z	must be a full path or shorthand device name
182	2026-04-21T20:34:44.179Z	+ _exit_trap

I have come to suspect that this is due to one of the disks on sock being in a bad way.

[jgallagher]

LGTM, just a couple small nitpicks.