Flat GPU catalog with search, and a root /node-pools endpoint with filters

Context

The node-pool registration form on the front branch refactor-node-pool-gpu-declaration uses GET /gpu-models with two selects: first a card model, then one of its partitions. The branch maintainer asked for a simpler UI with a single searchable select. The Runner's hierarchical catalog (a model containing its partitions) does not fit that UI.

What we want (Runner)

1. A flat GPU catalog. The catalog becomes one row per (brand, model, partition), and the whole card is the partition full. Each row has a stable gpu_config_id, e.g. nvidia-a100-80gb-mig-1g.10gb or nvidia-t4-full. The id is derived from the (gpu_model, gpu_mode) that node pools already store, so no migration is needed.
2. GET /gpu-models?search=… returns this flat list. The search is a token text search over brand, model and partition: every whitespace-separated token must match, case-insensitively. For example, a100 1g returns the 1g slices of both A100 cards.
3. A root /node-pools resource, outside /sites/{id}:
   • GET /node-pools takes these filters:
     • gpu_config_ids (list)
     • site_ids (list)
     • cpu_min / cpu_max, in cores
     • memory_min / memory_max, in bytes
   • POST /node-pools takes site_id in the body and an optional gpu_config_id, from which the Runner fills gpu_model and gpu_mode.
   • GET, PUT and POST …/archive on /node-pools/{id}.
   • The response includes site_id and gpu_config_id.
   • The nested /sites/{id}/node-pools* routes stay but are marked deprecated (ryaxctl and front master use them).

/gpu-models has not been released yet, so changing its shape does not break a released API.

Out of scope

• Adapting the front. The front branch owner switches to one select over /gpu-models and sends gpu_config_id on POST /node-pools.
• Regenerating the API spec.