LTX-2.3 blueprints: First-Last-Frame uses standalone distilled checkpoint while Text/Image-to-Video use dev+LoRA — undocumented inconsistency risks breaking either if "harmonized"

### Summary

The three LTX-2.3 blueprints load their model two different ways, with no comment or doc explaining why:

- **Text to Video** / **Image to Video**: `CheckpointLoaderSimple` loads `ltx-2.3-22b-dev-fp8.safetensors`, then `LoraLoaderModelOnly` applies `ltx-2.3-22b-distilled-lora-384.safetensors` at strength 0.5.
- **First-Last-Frame to Video**: `CheckpointLoaderSimple` loads `ltx-2.3-22b-distilled-fp8.safetensors` directly — no LoRA loader.

All three otherwise sample identically (`ManualSigmas` + `CFGGuider` + `SamplerCustomAdvanced`, the fast few-step path), so this isn't FLF2V needing a different pipeline — it's purely two different ways of getting the same distilled speed-up (a baked-in checkpoint vs. a LoRA overlaid on the full Dev model). I couldn't find any comment, PR description, or doc explaining the split. Confirmed this matches the current live content of [Comfy-Org/Subgraph-Blueprints](https://github.com/Comfy-Org/Subgraph-Blueprints) exactly — not something introduced downstream.

Files (as vendored into this repo under `blueprints/`, identical to the source repo):
- `Text to Video (LTX-2.3).json`
- `Image to Video (LTX-2.3).json`
- `First-Last-Frame to Video (LTX-2.3).json`

### Why this is worth documenting even though nothing is provably broken today

Both checkpoints are legitimate published artifacts, so nothing is wrong *right now* — but the undocumented split is a trap for whoever touches these files next:

1. **"Harmonizing" FLF2V onto the T2V/I2V pattern would inherit a known, currently-open bug.** #13887 reports exactly the `ltx-2.3-22b-dev-fp8.safetensors` + `ltx-2.3-22b-distilled-lora-384.safetensors` combination failing in `SamplerCustomAdvanced` with a tensor size mismatch, still open. A contributor "fixing" this inconsistency for consistency's sake would silently turn a working template into a broken one.
2. **The reverse fix carries its own risk.** Switching T2V/I2V onto the standalone `distilled-fp8` checkpoint to match FLF2V changes the actual model weights/quantization path in use, with nothing establishing the two are equivalent in quality or behavior — a plausible-looking cleanup that's actually an unreviewed model swap.
3. **It's a bad template for downstream authors.** These blueprints exist to be copied/extended. Someone building a new workflow off either one has no way to tell, from the files themselves, whether the loader pattern they're copying was a deliberate choice or an oversight.

### Suggested resolution

Not asking for a checkpoint change — just a one-line comment/description on each blueprint's model loader (or in the repo README) stating whether the dev+LoRA vs. standalone-distilled choice per workflow is intentional and why, so it stops looking like an unreviewed inconsistency.

Compare the model-loader nodes in `Text to Video (LTX-2.3).json`, `Image to Video (LTX-2.3).json`, and `First-Last-Frame to Video (LTX-2.3).json`; read the linked issue and source blueprint context first. Confirm the intended distinction with project maintainers or existing documentation, then add a concise explanation to the affected blueprints or README without changing checkpoints.

Written by the indexing model from the issue text.