Design: multiple accelerator vendors in the serving stack

[haarchri]

Description of your changes

The serving stack we propose in #422 is NVIDIA-only by construction: every clouds component list installs the NVIDIA operator or DRA driver, the GPU taint and toleration are nvidia.com/gpu, and nothing checks that the devices an InferenceClass declares match the stack its cluster gets.
AMD Instinct GPUs are reaching the clouds Modelplane targets, and TPU and Trainium sit behind the same gap: a cluster may carry devices from more than one vendor, and the stack must install each vendors components exactly where that vendor's devices are.

The design treats the vendor as data that already exists: a class devices[].driver names it (gpu.amd.com, gpu.nvidia.com), the cluster composition derives the vendor set onto the ServingStack, and the component join filters vendor-tagged components to the vendors present. Mismatches fail early in the composition functions, on the class, on the class/cluster pairing, and in the join. The aicr-generated cloud halves are deliberately untouched until a second vendor is installable on a managed cloud.

Design only, no implementation. Feedback wanted on the tag semantics ("part of one vendors device stack", untagged always installs), the per-cloud vendor table and its mirrors in the two functions that need it, and on deferring the generate.py vendor classification.

Fixes #

I have:

• Read and followed Modelplane's contribution process.
• Run nix flake check (or ./nix.sh flake check) and made sure it passes.
• Added or updated tests covering any composition function changes.
• Signed off every commit with git commit -s.