feat(gpu): obtain and create a pgpu card's cyborg device profile

[SekiXu]

What type of PR is this?

/kind feature

What this PR does / why we need it

A pgpu card is unusable without its Cyborg device profile name — that is the
string a flavor's accel:device_profile has to be set to — and the only ways to
get it were openstack accelerator device profile list or the interactive
hex_cli gpu menu. A Web UI user could set a card to pgpu and then get no
further, which is exactly what the parent epic's "no root shell access needed"
goal rules out. sriovVgpu and migBackedVgpu need nothing of the sort: their
PCI alias is minted by gpu_resource_set and already travels with the card.

Five commits, each self-contained:

commit	what
refactor(gpu): derive a device profile name through one shared function	one naming function, used by both the create and the report path
feat(gpu): report the device profile of every pgpu card on a node	gpu_device_profile_map / _get — one Openstack round trip for the whole node
feat(gpu): create a pgpu card's device profile without asking cyborg	gpu_device_profile_ensure — idempotent, no dependency on Cyborg's inventory
feat(gpu): give a pgpu card its device profile when it is carved	config_gpu.cpp calls ensure on a successful carve
feat(gpu): add a per-card device_profile_ensure to the gpu CLI	cli_gpu.cpp, for a card that predates this change

Ensure does not ask Cyborg for the card's model, because at the instant a carve
succeeds Cyborg does not know about the card yet: its nvidia driver learns which
cards are passthrough by reading hex's config.json, but only on the agent
period (default 60s). Asking would mean either blocking the carve for up to a
minute or creating nothing. Both values are available locally — the model name
in config.json, the product id in sysfs, which stays readable after the card
is bound to vfio-pci.

Which issue(s) this PR fixes

Refs #818

Deliberately Refs, not Fixes — #818 is a User Story whose UI (#876) and API
(#886) halves are still open, so merging this must not close it.

Special notes for your reviewer

Two runtime defects that only a node could show are folded into the commits
that introduced them, rather than left as a follow-up fix commit. Both have
regression tests, and both are worth knowing about beyond this PR:

1. hex_sdk does not load modules across files. It takes the command's
   first underscore-separated segment as the module name and sources only
   sdk_<MOD>*.sh, so a gpu_* command never has sdk_os.sh loaded and every
   call into it died with "command not found" — at runtime, not at parse time,
   and not in a unit test that stubs the callee. _gpu_load_os_module pulls it
   in on demand, the way sdk_health.sh does for sdk_ovn.sh, except lazily:
   sdk_os.sh is 3300 lines and drags in os_cinder.sh, and sourcing it at the
   top of the file would tax gpu_device_list, which the API runs on every
   listing. The tests now exercise the real load path against a fake SDK_DIR.

2. gpu_sysfs_pci_addr returns a sentence, not an address, for exactly the
   cards this feature is about. nvidia-smi prints "No devices were found" on
   stdout (rc 6, empty stderr) for a vfio-bound card, so that helper's
   [ -z "$addr" ] fallback to config.json never fires and it hands the
   sentence back as an address. gpu_device_profile_ensure already reads the
   card's record, so it takes the address from there. The helper's own defect
   is left alone and gets its own ticket ([Bug] gpu_sysfs_pci_addr returns nvidia-smi's error sentence as a PCI address for vfio-bound cards #1486) — its entire fallback branch is dead
   code for the case it exists to handle.

One more thing that matters more than it looks: the groups document is built
in one place, os_device_profile_groups_for. Those trait names are wrong on
Caracal — cyborg emits a single CUSTOM_NVIDIA_<PID> there (#1478) — and
os_nova_pgpu_host_list_by_instance_id parses the groups back out by field
ordinal, so a change in how many traits a group carries breaks live pgpu
migration silently. Keeping the document in one function keeps that fix to one
place.

Verification

• 45 offline tests green (10 naming / 19 map / 16 ensure), and green at every
  commit in this PR, not just at the tip.
• cn13, end to end: query → create → GET /gpuCards. ensure creates
  rtx_pro_6000_blackwell_server_edition_1 with the expected traits; the API
  reports it on the pgpu card and null on the other three.
• cn13: automatic ensure on carve, including the restore path — the card used
  for that test is back to IDENTICAL config.json, numvfs=48, driver=nvidia.

Two limitations QA needs to know, neither caused by this PR

• cn13 cannot prove a pgpu VM boots: 148 resource providers there report
  PGPU ([Bug]: cyborg advertises vGPU VFs and carved PFs as allocatable PGPU, so pgpu scheduling collides with running VMs #1262's fix only applies on Caracal; cn13 runs a March Yoga ISO), so a
  pgpu request can land on a vGPU VF and fail in libvirt.
• On Caracal the name cannot yet be scheduled against ([Bug] Caracal's cyborg renames GPU traits, so every pgpu device profile fails to schedule #1478). This PR makes
  it obtainable; [Bug] Caracal's cyborg renames GPU traits, so every pgpu device profile fails to schedule #1478 makes it usable. They ship together.

Related PRs: bigstack-oss/cube-cos-openapi#113 (field contract, merges first),
and the cube-cos-api handler PR, which opens once #113 is merged and its submodule
pointer can be re-pointed at a SHA on develop. This one can land in any order relative to the
API side — the field simply reads null until hex can answer.

Additional documentation