Plaid v2: reproduce v1's BPS-driven price for 7 Transfer SKUs

Ports v1's min(marginFlat, bpsFlat) price path into a v2 variable so 7 dynamic Plaid Transfer SKUs price to the cent against the v1 source of truth.

1. Why this exists

Plaid's v1 system (penguin) is still the source of truth for live pricing. Seven Transfer SKUs price dynamically off a BPS rate table, not off a flat list price. In prod, every tier's recommendedPricing is null, so the live formula isn't cost/(1-margin) — it's the BPS fallback.

The v2 migration (dealops-xq9.36) needs v2 to reproduce v1 verbatim for these SKUs before opportunities can be cut over. This PR ports the path that actually runs, not the dormant margin branch.

2. The 7 SKUs

Each tier table has 37 breakpoints from tierMin: 0 to tierMin: 500000 with 4 approval levels per tier (level1…level4).

3. The formula

4. What changes

4a. The pricingSpec.json flip

Each of the 7 SKUs swaps its listPriceVariableId and adds an inline bpsTransferPricing block under calculationSpec:

"listPriceVariableId": {
  "name": "listPriceTop"
}

"listPriceVariableId": {
  "name": "transferBpsPrice"
},
"bpsTransferPricing": {
  "cost": 0.162,
  "priceFloor": 0.34,
  "priceCap": 5,
  "currency": "CAD",
  "correspondingBpsProductId": "aacb55e7-…",
  "tiers": [ /* 37 rows */ ]
}

4b. Schema widening

packages/types/v2/productSpec.ts grows a bpsTransferPricing field on calculationSpecSchema (+44 lines). This is what lets productSpecSchema.safeParse validate the new SKU shapes — the realspec test asserts this directly.

4c. The helper

Pure function in bpsTransferPrice.ts:

export interface BpsTransferPriceInput {
  tiers: BpsTransferTier[];
  monthlyVolume: number;
  transactionSize: number;
  level: BpsApprovalLevel;     // 'level1' | 'level2' | 'level3' | 'level4'
  cost: number;
  priceFloor?: number;
  priceCap?: number;
}
export function computeBpsTransferPrice(input: BpsTransferPriceInput): number;

The registry variable in registry.ts wires it to v2 by reading three things off FormulaEvaluateAttr:

• the inline bpsTransferPricing block off attr.productSpec.calculationSpec
• the customer's effective monthly minimum via the existing getEffectiveMonthlyMinimumValue path
• the avgTransactionSize term (existing Plaid currency term)

It returns a NumberCurrency at level1 (list price). No engine-core touched.

5. How it lines up with v1

Three test files lock the behavior:

{
  "name": "Instant Payouts - Fixed",
  "dynamicProductId": "fcb372d4-…",
  "correspondingBpsProductId": "aacb55e7-…",
  "currency": "CAD", "cost": 0.162,
  "priceFloor": 0.34, "priceCap": 5,
  "tierCount": 37,
  "tiers": [ /* 37 rows */ ],
  "cases": [
    { "label": "low-volume tier500, txn50",
      "monthlyVolume": 600, "transactionSize": 50,
      "selectedTierMin": 500,
      "expected": { "level1": 0.625, "level2": 0.5, "level3": 0.425, "level4": 0.34 } },
    { "label": "huge txn -> hits cap",
      "monthlyVolume": 600, "transactionSize": 100000,
      "expected": { "level1": 5, "level2": 5, "level3": 5, "level4": 5 } }
  ]
}

6. Worked example

Instant Payouts — Fixed (CAD), customer at monthly minimum 600, avg transaction size $50, level1:

1. Tier select: T.tierMin = 500 (highest tier ≤ 600).
2. 0→500 quirk: T.tierMin ≠ 0, so R = T.
3. R.level1 = 1.25 (percent).
4. bpsFlat = 1.25 × 50 × 0.01 = 0.625.
5. recommendedPricing null → marginFlat = bpsFlat = 0.625.
6. clamp(0.625, 0.34, 5) = 0.625 CAD ✓

7. What it doesn't change

8. Risks & rollback

9. Out of scope (per PR)

• Opportunity migration + historical-quote replay → dealops-xq9.36.7
• cost_plus_margin dispatch scaffolding → dealops-xq9.36.5 (the base of this stack)