Previously a per-request LoRA could only be a local path or HF id, which
assumed the client shared the server's filesystem. Add a content-addressed
store so remote clients can supply LoRAs by value or handle.

Request `loras` spec now accepts (resolved server-side, in priority):
  id "name:<registered>"  -> a LoRA trained on this server (path-independent)
  id "sha256:<hex>"       -> a previously uploaded blob
  file/data (base64)      -> inline weights, cached in the blob store
  url                     -> server downloads (cached by content hash)
  model/path              -> legacy local path / HF id (unchanged)

- loras.py: blob store (save_lora_blob / lora_blob_exists / _lora_blob_path),
  resolve_lora_ref(), resolve_request_loras() (in-place -> clean 400 on a
  missing blob / unknown name). New POST /v1/loras/upload (multipart / JSON
  base64 / raw, dedup) and GET /v1/loras/blob/{hash} existence check.
- LoraConfig / VideoLoraConfig: model now optional; add id/url/file/data/path.
- image + video handlers resolve_request_loras() before model work, so
  signature dedup / VRAM reserve / load_lora_weights read lora.model as before.
- gen_township_fighters.py: reference trained LoRAs by id "name:<registered>"
  (derived from the server path) with the raw path kept as a co-located
  fallback, so the script works client/server-split.

Also harden video load: float(cfg.get('balanced_gpu_percent', 80)) crashed on
an explicit null (admin UI writes null for blank fields); use `or 80`.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>