Auto-seed pending renewals when the prior contract changes

Phases 4 & 5 of RFC 2026-06-01: a platform-event reactor keeps PENDING renewal quotes in sync as the prior contract evolves, and an explicit re-seed mutation rebuilds a renewal when the rep moves its start date earlier.

1. Why this exists

RFC 2026-06-01 introduces a single utility — computeContractStateAsOf(steps, asOfDate, expansionMode) — and progressively rewires three consumers around it. Phases 1–3 shipped in #5735 and fixed renewal creation (no more catalog-default surprises). This PR lands the remaining two consumers:

2. Walkthrough: how the reactor fires

Step through what happens when an amendment closes on an active contract that already has a PENDING renewal sitting behind it.

3. Before / after: the seed builder split

The original buildEngagementRenewalSeed needed an AuthedTRPCContext (for ctx.prisma and ctx.user) and gated on a hard-coded set of CRM opp-type strings. Neither works for background jobs or for orgs whose CRM vocabulary differs.

async function buildEngagementRenewalSeed({
  ctx,            // tRPC ctx required
  opportunityV2Id,
  organizationId,
  userId,
}) {
  const oppType = await getOpportunityType(...);
  if (!RENEWAL_OPP_TYPES.has(oppType)) return null;
  // ^ misses Langchain's
  //   "Renewal Opportunity"

  if (!useEngagement) return null;
  const priorDealGroupId = await resolvePrior...(
    opportunityV2Id, ctx.prisma,
  );
  // ... resolve + assemble seed
}

// Core: usable from jobs + handlers
async function resolveEngagementRenewalSeed({
  opportunityV2Id,
  organizationId,
  oppType,              // only for DEA-6043 filter
  renewalStartOverride, // NEW — early renewal
  priorDealGroupId,
}) { /* ... */ }

// Wrapper: structural gate first
async function buildEngagementRenewalSeed(...) {
  const priorDealGroupId =
    await resolvePriorContractDealGroupId(oppId);
  if (!priorDealGroupId) return null;
  // ^ sequence-1 head check covers
  //   every org's renewal vocabulary
  if (!useEngagement) return null;
  return resolveEngagementRenewalSeed({...});
}

4. New surface area

5. The date-change client flow

In DateTerm.tsx, when a renewal's start date moves earlier the rep gets a destructive-confirmation modal before anything fires:

const isMovingEarlier =
  !!isoString && !!currentIso && isoString < currentIso;

if (isStartDate && canReseedFromPriorContract && isMovingEarlier) {
  showConfirmationModal(
    {
      title: 'Rebuild renewal for earlier start date?',
      message: `Moving the start date to ${isoString} rebuilds this renewal
                from the prior contract as of that date, replacing the
                current products and pricing. Continue?`,
      confirmLabel: 'Rebuild quote',
      isDestructive: true,
    },
    () => {
      void reseedRenewalStartDate(isoString)
        .then((reseeded) => {
          if (!reseeded) handleValueChange(isoString); // fall back
        })
        .catch(() => showToast({ type: 'error', ... }));
    },
  );
  return;
}
handleValueChange(isoString); // unchanged path for all other edits

On a successful re-seed the provider calls window.location.reload(). This is deliberate, not lazy — see the open question below.

6. Loop-safety

7. The structural renewal gate

The cleverest part of this PR is a one-line strengthening of resolvePriorContractDealGroupId:

// Only the renewal that *opens* a Contract DealGroup (sequence-1 head) seeds
// from the prior contract — an amendment/expansion living deeper in the same
// renewal contract (sequence 2+) renews from its own head, not the prior
// contract. This structural check is what identifies a renewal, NOT the CRM
// opp-type string (which varies per org — Langchain renewals don't all read
// "Renewal"/"Renewal Opportunity").
currentMembership.sequence !== 1

That single check replaces the old RENEWAL_OPP_TYPES set lookup. Three things follow:

8. What it doesn't change

9. Risks, open questions, follow-ups