Modify PO card shows '(unresolved)' for freshly-added variants not in the typed cache

[dougborg]

Problem

On the "Modify Purchase Order Applied" card, newly-added line items can render with SKU (unresolved) and item name variant <id> (e.g. variant 40933338, variant 40707820) instead of their real SKU / display name.

Observed alongside the stale-total bug (fixed in the PR that references this issue) — see the screenshot in that PR's linked session.

Root cause

Added-row SKU/name resolution goes through _resolve_po_row_variants in katana_mcp_server/src/katana_mcp/tools/foundation/purchase_orders.py, which looks variants up only in the typed-cache catalog:

variants = await services.typed_cache.catalog.get_many_by_ids(
    CachedVariant, variant_ids, include_archived=True, include_deleted=True
)

A cache miss yields {"sku": None, "display_name": None} → the card falls back to (unresolved) / variant <id> (foundation/po_row_table.py). There is no API fallback (no get_variant_details). So any variant not yet synced into the local catalog — a recently-created variant, or one outside the synced window — renders unresolved even though the add succeeded.

The post-apply CacheMerge refreshes the PO and its rows, not the variant catalog, and resolved_variants is computed before the plan runs — so neither helps here.

Proposed fix

Add an API fallback for cache-miss variant ids in _resolve_po_row_variants: after the batch cache lookup, for any id still unresolved, fetch via get_variant_details (batched / bounded) and (optionally) warm the catalog. Weigh the extra API calls — only fire for the miss set, and cap/bound to avoid rate-limit pressure on large adds.

Acceptance

• Adding a variant absent from the local catalog renders its real SKU + name on the modify PO card.
• No regression for the common cache-hit path (no extra API calls when all ids resolve from cache).

Workstream: Cache / Fulfillment. Priority: P2-soon (cosmetic on the card; the write itself is correct).