webui: point every catalog entry at the package it installs

[CryptVenture]

Reopened now that #400 has merged, rebased on current main. The voxcpm1 download_id fixed in #424 is kept as it is.

The problem

60 of the 85 catalog entries do not describe a package that exists:

• 46 name a download_id that is not a packages[].id in any model_specs/*.json.
• 14 name a path that is not models/<target_directory> of the package they point at.

They resolve only through a compatibility shim in catalog.ts that strips precision suffixes and guesses. Where the guess fails, the entry offers no install button at all.

The change

Each entry names the package it already meant, and the directory that package installs into.

• download_id becomes an exact packages[].id from the entry's own family. A stem (omnivoice, chatterbox) becomes the family's recommended package; a variant (qwen3_tts_1_7b_custom_voice, dots_tts_mf_q8_0) keeps the variant and only has its spelling corrected to the published id.
• path becomes models/<target_directory> of that package. 40 entries pointed at pre-GGUF directories no package writes (models/chatterbox → models/Chatterbox-GGUF); several pointed at one .gguf file inside the directory, which only resolves while that exact filename ships.
• Three entries resolved to safetensors packages the native manager cannot install, so they had no install choice at all; they now use their family's recommended GGUF package.

No entry is added, removed or retasked. Display names, tasks, modes and min_vram_gb are untouched. 60 lines changed, 60 replaced.

Verification

entries whose download_id is not a packages[].id      46 -> 0
entries whose path is not the package target_directory 14 -> 0
paths targeted by more than one download_id            0
tools/check_loader_catalog_sync.py                     ok, loaders/model_specs/model_manager_v2 in sync

No path is claimed by two packages, so a catalog install leaves one package per directory.

Directory paths load exactly as the file paths they replace — same server, same input, audiosr registered twice:

models/AudioSR-GGUF                          200  ["audio","channels","sample_rate","timing"]
models/AudioSR-GGUF/audiosr-basic-f32.gguf   200  identical

The one entry where this matters most is minimax-h3, which moves from models/MiniMax-H3-Q4-GGUF/dit.gguf to the directory: load_minimax_h3_assets takes either, and the directory is the spec-driven path that reaches the whole component package rather than the DiT alone.