Admin Agent goes table-native for the product catalog

The product sub-agent now reads and writes catalog_product rows directly — the legacy pricingSpec.productSpecs + datasheet authoring path is retired for product work.

1. Why this exists

Product authoring in V3 has lived in two places at once: the inline pricingSpec.productSpecs map (a JSON blob, versioned as a whole) and per-product datasheet datapoints for list pricing. Earlier PRs in this stack (see base branch pk/catalog-live-draft-api) introduced a real SQL table — catalog_product with live/draft states — and started routing reads through it behind an org-scoped allow-list.

This PR removes the seam. The Admin Agent now treats catalog_product as the only product source, the legacy blob is no longer authored, and the read flag is deleted. The RFC at rfcs/2026-06-18-admin-agent-table-backed-product-catalog.md (+839 lines) documents the new boundaries.

2. Before / after at a glance

3. The new product data flow

The orchestrator/planner stays the same — it still delegates product work to the Product Catalog sub-agent. What changed is what tools that sub-agent receives and where its reads and writes land.

4. Where the legacy authoring path goes

The biggest behavioral cut is in trpc/router/v3Admin/updateProduct.ts. Its existing public surface is preserved (admins keep editing products in the UI), but the implementation is rewritten:

UpdateProductDeps = {
  catalogProductEnabled(orgId): boolean
  loadPricingSpecForEdit(...)
  loadDatasheetForPreview(...)
  saveDraft(slug, user, specType, data)
}

UpdateProductDeps = {
  loadEffectiveProduct(...)
  upsertDraftProduct(
    orgId, userId, skuId,
    identity, content,
    isDeleted, pricebookId,
  )
}

The test file catalogProductUpdateProductAuthoring.test.ts was rewritten to match — its three new cases assert: (1) a list-price edit lands as flat_price on a draft row, (2) attribute-only edits leave price as {}, and (3) attributes.isActive is mirrored onto the table's isActive column.

5. What the sub-agent's tool box looks like now

{
  skuId: string,             // stable product id
  name?: string,             // required on create
  skuName?: string | null,
  baseProductId?: string,
  baseProductName?: string,
  attributes?: Record<string, AttributeValue>,
  structuralFields?: {       // calculationSpec, pricebookIds,
    [k: string]: unknown     // listPriceCurrencies, order, ...
  },
  price?: ProductPrice,      // exactly one of flat_price |
                             //   tiered_price | composite_price
  pricebookId?: string,
  pricebookIds?: string[],
  listPriceCurrencies?: string[],
  crmProductId?: string | null,
  isActive?: boolean,
}

6. Draft lifecycle: publish, discard, status

Catalog products become a first-class draft layer alongside the existing spec drafts.

7. Runtime compatibility (V3 → V2)

The pricing engine still consumes V2-shaped specs, and the assembled V3PricingSpecData shape is intentionally unchanged. Only the source of productSpecs moved.

if (!deps.catalogProductEnabled(orgId)) {
  // Flag OFF: return blob's inline
  // productSpecs verbatim
  return { ...body,
           productSpecs: body.productSpecs };
}
// Flag ON: source from table
return { ...body,
         productSpecs: await loadLive...() };

// No flag. productSpecs ALWAYS
// from catalog_product.
// Blob supplies non-product envelope.
if (mode === 'live') {
  return { ...body,
    productSpecs: await deps.loadLiveProductSpecs(orgId) };
}
return { ...body,
  productSpecs: await deps.loadPreviewProductSpecs(orgId, userId) };

For the V3 → V2 conversion path (createPreviewQuote, publish sync), product list-price datasheet entries are now derived from catalog_product.price via deriveV3Datasheet. The agent never authors product list-price datapoints anymore; that surface exists only as runtime glue.

8. What this PR does not change

9. Risks & things to watch

Open questions for the reviewer

• Is there a separate migration story for orgs whose product data still lives only in pricingSpec.productSpecs? The RFC presumably covers it; worth confirming the rollout order with the base branch's work.
• Several legacy product tools (setProductPriceTiers, bulkWriteProducts on the legacy path) are no longer reachable from the sub-agent. Are they still referenced from anywhere else, or can the files be deleted in a follow-up?
• The orchestrator now lists both listProductsSummary and listCatalogProductsForAgent in its read-tool set. Worth a pass to make sure prompts don't push the model to call both redundantly.