…p from one source

- export proActivationStepId from convex/schema.ts and import it in
  convex/payments/billing.ts instead of a hand-duplicated literal union
  (schema.ts and billing.ts previously listed the same 3 literals
  independently, with nothing to catch drift)
- derive MAX_PRO_ACTIVATION_OUTCOME_REVISION and the disjoint-steps bound
  from proActivationStepId.members.length instead of hardcoded literals
  (4 and 3), which had zero headroom above the wizard's exact worst-case
  call count and would silently start rejecting writes if a step or a
  progress-call site were ever added

Found in ce-code-review of #5584 (forward-ported here as #5590); both
findings independently validated. Convex billing suite (149/149) and
full typecheck pass unchanged.

…stitial

openProActivationFlow opened the interstitial (wiring onProgress/onExit to
recordProActivationOutcome) BEFORE awaiting confirmPresentationWithRetry.
If a user interacted with a step in the window before that awaited call
resolved and confirmPresentationWithRetry then failed (lost claim
ownership, or transport errors exhausting the retry schedule),
recordProActivationOutcome's own defensive presentedAt backfill had
already fired -- permanently blocking a legitimate future re-claim via
claimProActivationPresentation's already_presented check, even though the
server never actually acknowledged this presentation.

Move the confirmPresentationWithRetry await ahead of
dependencies.openInterstitial(...) so the interstitial (and therefore its
onProgress/onExit handlers) cannot exist until the presentation is
genuinely confirmed. subscribeAuthState's reactive stale-account guard is
unaffected: it still subscribes immediately after open and checks current
state synchronously on subscribe.

Adds a regression test (e2e/pro-activation.spec.ts) that holds confirm
pending, asserts the interstitial is not mounted while it is in flight,
then resolves confirm with failure and asserts no outcome write occurred.
Verified red on the prior ordering (overlay count 1 while confirm was
pending) and green on this fix.

Found in ce-code-review of #5584 (forward-ported here as #5590; the
presentedAt/claimProActivationPresentation code is unchanged by later
outcomeTrackingVersion commits on this branch). Full e2e/pro-activation
spec (22/22), frontend typecheck, and lint pass.

…give-up path

Two test gaps flagged in ce-code-review of #5584/#5590:

- tests/report-activation-lift.test.mjs: no test drove
  analyzeActivationLift() to the 'no-mature-outcomes' verdict -- the state
  the script is realistically in immediately post-launch, before any
  presentation has completed its observation window. Adds a case with
  every presentation still immature and asserts the verdict, empty
  engaged/presentedOnly summaries, and the formatted report message.

- e2e/pro-activation.spec.ts: no test exercised
  persistActivationOutcomeWithRetry's retry-then-give-up path -- the
  existing recordOutcome mock always resolved true. Adds an
  outcomeAlwaysFails harness option and a test asserting exactly 3 attempts
  (1 initial + the 2 scheduled OUTCOME_WRITE_RETRY_DELAYS_MS retries), that
  it stops retrying afterward, and that the best-effort failure never
  blocks the flow (summary stays interactive, finish still closes the
  overlay).

Full e2e/pro-activation spec (23/23), report-activation-lift tests (7/7),
typecheck, and lint pass.