test(word-addin): cross-package drift guard for the hand-mirrored catalog

The Word add-in mirrors the web app's model catalog by hand
(word-addin/src/taskpane/lib/modelCatalog.ts carries a "keep in sync"
comment and nothing enforcing it). This adds the enforcement.

WHY THIS MATTERS
Two hand-maintained copies of the same catalog WILL drift: an id gets
renamed on the web, a label is tweaked in the add-in, a defensive strip
sneaks into one client's option builder (exactly what the F1 commit
removed). Every such drift ships two different products - a model the
web offers that the add-in doesn't, a composer that sends a different
model string for the same stored selection - and nothing red-flags it
until a user notices. A shared package is the real fix; extracting one
is out of scope for this stack and flagged as a follow-up in the PR
body. Until then, CI has to catch the drift.

HOW IT WORKS
frontend/src/wordAddin/catalogParity.test.ts imports BOTH catalogs (the
frontend test runner transforms the add-in's TypeScript across the
package boundary; the add-in's modelCatalog imports its ApiKeyStatus
type from the office-free api/client so the compile graph stays clean)
and pins:
- the add-in's STATIC_MODELS equal the web MODELS (id, label, group);
- both clients share DEFAULT_MODEL_ID;
- modelDisplayName renders identical output for every shared id,
  router-namespaced and ollama forms included;
- the option builders emit the identical composer model id for the same
  stored selection (including router-slug catalog ids);
- availability gating agrees: for each provider configured alone, every
  shared id is available in the add-in iff it is available on the web.

Sanity-checked by hand-editing one add-in label ("GPT 5.5 Turbo") and
watching the suite fail; the composer-string case is the same assertion
that pinned the F1 divergence.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>