feat(tuning): register nova.nested.virt.enabled for the compute roles

[traviswu-bigstack]

What

Fixes #648.

Registers the nova.nested.virt.enabled tuning introduced by bigstack-oss/cubecos#1365 (the fix for bigstack-oss/cubecos#1361) so the API advertises it against the roles that actually apply it.

tuningToRoles[NovaNestedVirtEnabled] = nodes.ComputeRoles — {compute, control-converged, edge-core}.

Why

The tuning's only effect is cpu_model_extra_flags in nova.conf's [libvirt] section, written under if (IsCompute(s_eCubeRole)) in config_nova.cpp — so control-only, storage and moderator nodes never act on it. Without an entry in the map, getTuningRoles falls back to nodes.AllRoles (tuning.go:452), which would advertise it on nodes where libvirt does not run.

ComputeRoles matches the sibling hypervisor-scoped tunings (nova.gpu.type, nova.control.host.memory). It is deliberately narrower than novaLiveResizeRoles, which includes control and moderator because live-resize also constrains nova-api/scheduler behaviour; nested virt does not.

The value must be uniform cluster-wide, which this role set expresses: every compute-capable node applies the same setting. A host exposing vmx while its peers mask it would hand a migrated guest a different CPU than it booted with — the same class of inconsistency cubecos#1365 exists to prevent.

Reviewer notes

• No docs.yaml change: the tuning entries there are illustrative response examples, not a validating enum, and they already omit the nova.live.resize.* family — adding only this one would be inconsistent. Say the word if you would rather the examples be exhaustive.
• Depends on cubecos#1365 landing for the tuning to exist in hex_sdk tuning_dump; until then setTuningSpecs simply never sees the name and the map entry is inert, so merge order does not matter.

Docs

Behaviour is documented by cubecos#1365's handbook note; no separate handbook change proposed here.