[refactor] v2: shared model registry (HF-id primary + arch fallback) for all entrypoints

Per review: dispatch should be a directly-mapped HF-string -> card registry (like fastvideo), shared
by every entrypoint (VideoGenerator + a future CLI / server), not buried in the generator.

- New v2/registry.py mirrors fastvideo's fastvideo/registry.py hybrid resolution: (1) exact HF repo id
  in an explicit ModelEntry registry [PRIMARY — correct per-model card/capabilities, and the only way to
  split same-architecture capability variants like Wan2.1 T2V vs the i2v 'InP' 1.3B], (2) short repo-name
  match, (3) architecture inference [FALLBACK — local paths / unregistered repos]. resolve(model_path[,
  root]) is the single shared entry point.
- video_generator.py: moved _read_arch_signature/_select_builders into the registry; from_config now
  calls resolve() — registered ids resolve with no config read, else arch inference on a cheap *.json
  snapshot. Reconciles the earlier 'no brittle table' refactor with the 'map hf string -> card' ask: one
  clean registry + a fallback, not three coupled structures.
- Verified: registry resolves exact-id / short-name / arch-fallback / unregistered correctly; CPU suite
  green (202+2); wan21 GPU smoke generates via the new resolve path.

examples/inference/basic/V2_PORTING_STATUS.md

@@ -65,8 +65,10 @@ Each would need a new card + adapters (DiT/VAE/encoder forwards) + maybe a sampl
 
 ## How to add a model to the v2 VideoGenerator
 1. Ensure a v2 card exists (`v2/models/<family>/`) whose `load_id`s resolve to real `fastvideo.models.*`.
-2. Dispatch is automatic: add a branch in `v2/video_generator.py:_select_builders` keyed on the new
-   architecture (transformer/pipeline/VAE class names) — no HF-id table to edit.
+2. Register it in the shared `v2/registry.py` (used by every entrypoint — VideoGenerator, CLI, server):
+   add a `ModelEntry` mapping its HF id(s) → builders (the explicit PRIMARY path — the only way to split
+   same-architecture capability variants, e.g. T2V vs the i2v "InP"), and/or a branch in
+   `select_by_architecture` for the arch-inference FALLBACK (local paths / unregistered repos).
 3. If a DiT/VAE/encoder/upsampler forward differs, add an adapter + class-detection in `torch_adapters.py`
    and register the component kind in `torch_cuda.py`.
 4. Add `examples/inference/basic/v2_<name>.py` mirroring the official example; generate to confirm.