fix(dash): derive model.type at useModels so Load-now matches slots

[thinmintdev]

Summary

Clicking Load now on any model in the catalog (whisper-tiny, embed,
chat, rerank, …) currently toasts:

No slot accepts type=? — create one in Slots

even when a compatible slot is running. Reproduces every time on a stock
v0.3 install (live API + local repro).

Root cause

/api/models rows ship capabilities: ['transcription' | 'chat' | 'embed' | …]
and leave type unset — the registry has no type field. Slots carry
the dispatcher vocabulary (llm | embedding | reranking | transcription | tts | image). The join in ui/src/dash/models.jsx:287:

const compatible = slots.filter(s => s.type === model.type);

…compares slot.type against undefined, so the filter is always empty
and the error fires regardless of how many compatible slots are running.

The exact mapping already exists, inlined in ui/src/dash/slot-modals.jsx
as a local normalizeApiModel — but models.jsx doesn't use it.

Fix

• Extract normalizeApiModel to ui/src/lib/normalizeApiModel.ts
  (typed, with SlotType union + capability/backend derivation).
• Apply it once inside useModels so every consumer sees type /
  device / size / longName / repo populated. Centralises the
  capability→slot-type mapping in one place — when a new capability
  lands, the join in models.jsx keeps working without touching it.

Kept in step with src/hal0/slots/manager.py:_VALID_SLOT_TYPES.

Test plan

• `npm run typecheck` clean
• `npm run build` clean
• `npx playwright test` → 75 passed, 16 skipped, 0 failed
• Manual: `curl /api/models` rows confirmed missing `type`; slot
  types confirmed `transcription | llm | embedding | reranking | tts`.

🤖 Generated with Claude Code