Validate pilot registration fields against the CS

### Context

`POST /api/pilots/` (added in #570) accepts `grid_type`, `grid_site` and `destination_site` as free strings, and `PATCH /api/pilots/metadata` similarly accepts `GridType`, `GridSite`, `DestinationSite` and `Queue` without validation. A typo silently creates pilots attached to nonexistent sites, which then pollutes accounting and monitoring groupings.

The `vo` field is already validated against the registry (400 for unknown VOs) since #570.

Legacy DIRAC's `PilotManagerHandler.addPilotReferences` performs no validation either, so this is an improvement over parity, not a regression fix.

### Blocker

The site list cannot be validated today: the diracx `Config` schema does not model the `Resources/Sites` section of the CS. `ResourcesConfig` currently only contains `Computing.OSCompatibility`, with `extra="ignore"` and its own TODO ("Remove this once the model is extended to support everything", `diracx-core/src/diracx/core/config/schema.py`).

### DoD

- [ ] Model `Resources/Sites` in the Config schema (with `DIRAC_COMPAT_ENABLE_CS_CONVERSION` support for the legacy CFG format, as done for `OSCompatibility`).
- [ ] Validate `grid_site` / `destination_site` / `grid_type` against the modeled site list on `POST /api/pilots/` and on `PATCH /api/pilots/metadata` (`GridSite` / `DestinationSite` fields). Same question applies to `Queue`.
- [ ] Decide the failure mode: reject with 400, or accept-with-warning for pilots from sites not (yet) present in the CS (relevant for vacuum pilots appearing at new sites).

Start with ResourcesConfig in diracx-core/src/diracx/core/config/schema.py and inspect the existing Computing.OSCompatibility model and DIRAC_COMPAT_ENABLE_CS_CONVERSION handling. Trace POST /api/pilots/ and PATCH /api/pilots/metadata, then define the Resources/Sites model, site and queue validation, and the agreed behavior for sites not yet present in the CS.

Written by the indexing model from the issue text.