Plaid v2: MM checkbox count scales TCV (dealops-3uy)

Wires v1's "monthly minimum type" checkbox-count multiplier into v2's contractual outputs (ramped TCV, flat-MM TCV, displayed minimum-commitment block) — narrowly scoped so non-Plaid orgs stay byte-identical.

1. Why this exists

In v1 (penguin), each checked "Monthly minimum type" box multiplied the contractual MM floor by the checkbox count. The rep picks 2 boxes, the MM floor doubles in TCV. v2 ignored this entirely — the term only fed the effectiveMonthlyMinimum formula variable used for SF writeback / approval-tier matching, but never landed in TCV or the displayed commitment block.

The narrow-scope contract

The PR explicitly carves the work into two pieces. This PR ships the contractual display + TCV piece. Per-product / aggregate revenue scaling (the applyMonthlyMinimumDiscount chokepoint) is deferred to dealops-9za so this PR doesn't touch core pricing-engine math for any non-Plaid org.

2. What changes

2.1 The fallback chain (the central idea)

Every TCV read in calculateSummary and buildTcvSegments now goes through a 3-link resolver. Each link returns null on quotes it doesn't apply to, so non-Plaid orgs fall through to plain getTCV byte-identically.

2.2 The additive marginal (the math)

For flat-MM Plaid quotes with multiplier mult > 1:

marginal = monthlyMinimumAmount × (mult − 1) × monthsInRange
result   = getTCV(year).value + marginal

This is additive, not multiplicative or max. It mirrors v1's SF writeback, which emits N separate MM QLIs summed alongside usage QLIs — no max-with-usage clamp anywhere. v2's applyMonthlyMinimumDiscount clamps semantics differ; closing that pre-existing v1↔v2 gap is dealops-j4u, not this PR.

2.3 The screenshot scenario — concrete numbers

Scenario: binding flat-MM quote, $10,000/mo floor, 12-month term, $1,000/mo usage → MM binds, base TCV = $120k. After fix-up, TCV scales linearly with N.

2.4 Engine: new methods and their gates

All three methods sit on PricingEngineService. Each has a tight set of early returns so non-Plaid orgs are provably unaffected.

getMonthlyMinimumMultiplier(): number {
  const scale = pricingSpecData.pricingEngineSpec
    ?.minimumCommitment?.scaleByAdditionalProductCodes;
  if (!scale) return 1;                          // non-Plaid identity
  const term = terms.find(t => t.id === ADDITIONAL_MM_TERM_ID);
  if (term?.userValue.type === 'array') {
    return term.userValue.value.filter(x => typeof x === 'string').length;
  }
  // CPQ-import fallback: singular code counts as 1
  const imported = minimumCommitment?.monthlyMinimumProductCode;
  if (typeof imported === 'string' && imported.length > 0) return 1;
  return 0;
}

2.5 Summary: where scaling lives

The summary scales response.minimumCommitment.{monthlyMinimumAmount, annualMinimumAmount, effectivePercentage} at the display boundary, not inside the engine's commitment readers. This keeps core math untouched.

const mmMultiplier = pricingEngineService.getMonthlyMinimumMultiplier();
const mmEnabledOnQuote = pricingQuoteInput.minimumCommitment?.enabled === true;
const commitmentScale = mmEnabledOnQuote ? mmMultiplier : 1;
const monthlyMinimum = { ...rawMonthlyMinimum, value: rawMonthlyMinimum.value * commitmentScale };
const annualMinimum  = { ...rawAnnualMinimum,  value: rawAnnualMinimum.value  * commitmentScale };

The mmEnabledOnQuote guard is a carve-out: when MM is disabled on the quote, the commitment readers return the usage-revenue fallback, which must not be scaled. Same carve-out the engine-internal version had.

2.6 CPQ-import fallback

2.7 Ancillary: the cycle break

The constant ADDITIONAL_MONTHLY_MINIMUM_PRODUCT_CODES_TERM_ID moved into a new zero-import sibling file PlaidEffectiveMonthlyMinimum.constants.ts. Importing it from …attr.ts would re-enter the plaid/registry ↔ attr ↔ formulaUtils ↔ evaluationEngine ↔ variables/registry ↔ plaid/registry init cycle and hit a TDZ error at module-load time. The .attr.ts file re-exports the constant for backward compat.

3. The PlaidWriteBack atomicity rework (sibling change in this PR)

This PR also carries a substantial rework to PlaidWriteBack.ts (+216/−211) under dealops-1q8. It's logically separate from the multiplier work but ships in the same PR.

Composite shape (with 1 primary quote + 3 OLIs)

Other guardrails added: a single-attempt contract (no retry — partial-success risk on Ampersand timeouts outweighs benefit), and a budget guard that throws PLAID_COMPOSITE_GRAPH_TOO_LARGE before any Ampersand call when sub-request count would exceed SF's 500-cap.

4. What it doesn't change

5. Risks & intentional consequences

6. Test coverage

One new spec file: pricingEngineMonthlyMinimumMultiplier.spec.ts (1345 lines, 47 tests, 4 describe blocks).

Plus a new PlaidWriteBack.atomic.test.ts (886 lines, TDD-red contract tests for dealops-1q8 GAP-ATOMIC) and 276 lines of obsolete preprocess-phase tests removed from PlaidWriteBack.test.ts.

Regression validation: 465 tests pass across 7 touchpoint suites (pricingEngineService, pricingEngineServiceProratedAndOthers, monthlyMinimum, tcv, dealDiscount, evaluationEngine, and the new MM-multiplier spec).

7. Follow-up bead map