fix(word-addin): map retired model ids, and pin that mapping in the guard

Adversarial review of this stack, pre-push: the rename-compat fix landed
in three places and missed the fourth.

WHY THIS MATTERS
The Word pane and the web composer store the user's model choice under
the SAME localStorage key, "mike.selectedModel" - same key name, same
value shape, written by whichever client the user touched last. The
hardening batch earlier in this branch taught the backend, the settings
page and the web composer to map retired ids (gemini-3.1-flash-lite-
preview → gemini-3.5-flash-lite, gpt-5.4-lite → gpt-5.4-mini) on read.
The add-in was not taught, so the same stored string resolved to the
renamed model in one client and to the fallback in the other.

THE PORT
`LEGACY_MODEL_IDS` and `canonicalModelId` are mirrored into the add-in's
modelCatalog, and its useSelectedModel canonicalizes both on read (the
stored value) and on write (an id handed in by the picker) - the same
two points the web hook does.

WHY THE GUARD MATTERS MORE THAN THE PORT
This class of bug is not "someone forgot"; it is structural. The add-in
mirrors the web catalog BY HAND, so every future rename can drift again.
catalogParity.test.ts already compared the model rows, labels, default
id and key gating; it now also compares LEGACY_MODEL_IDS entry-for-entry
and the accepted-id surface (isAllowedModelId) across the two packages.
To compare the accepted-id surface honestly rather than restating the
rule in the test, the web hook's private `isAllowed` becomes an exported
`isAllowedModelId` - the same name the add-in already uses.

Tests: the two new parity cases. Pre-fix the legacy-id case fails with
"expected undefined to deeply equal { gemini-3.1-flash-lite-preview: ... }"
- the add-in simply had no such export. The accepted-id case passes
before and after; it is a guard against the NEXT divergence, not a proof
of this one.

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