fix(realunit): close the PersonalData KYC step a completed registration satisfies

[Danswar]

Closes item 1 of #4556.

Problem

A completed RealUnit registration lifts the account to LEVEL_20 — which the KycLevel enum defines as personal data — but never closes the PERSONAL_DATA step that level represents.

For an account carrying an open step from an earlier, abandoned KYC attempt the step stays IN_PROGRESS permanently: the auto-completion in initiateStep is gated on !preventDirectEvaluation, which the presence of any prior step row sets, so such an account can never satisfy the step again. KycInfoMapper then keeps handing that stale step back as currentStep, the RealUnit client cannot render it, and onboarding dead-ends with no path forward.

Change

Reconcile the step with the level at every point that concludes the registration is durably in place. KycService.completeSatisfiedPersonalDataStep mirrors what updatePersonalData already does (complete → createStepLog → updateProgress) and reloads the account with kycSteps so the lookup never reads an undefined relation.

Deliberate constraints

• Never closes an unremedied re-opened step. isDataComplete is a non-null check, not a validity check. When Sumsub reports PROBLEMATIC_APPLICANT_DATA, restartStep fails the completed step and opens a fresh one so the user can correct data that is present but wrong — and the rejection marker lands on the failed row, so a pending-only lookup is no protection. The verdict comes from the most recent step carrying a settled verdict (KycStep.hasSettledVerdict), judged over the account's own chain only. Remediation is read from the step's result and the durable RESTARTED_STEP marker (KycStep.isRejected), not from its status alone: initiateStep cancels a merely pending step as well as a completed one, so CANCELED alone cannot tell an untouched retry from a remediation, whereas result survives cancel() and a step cancelled while pending never had one. A completion later revoked by restartStep keeps its stale result, so the marker — not the status — is what keeps it blocking. Merged-in rows are excluded — a merge seeds them below the floor and orders them chronologically only within a batch, so ranking across batches could let a stale cancellation outrank a newer rejection. Without this guard the retry would be re-completed with the same rejected data, skipping the correction step and stranding the user on Ident.
• Kept separate from ensureRegistrationKycLevel. That method returns early at LEVEL_20, which is exactly the state a stuck account is already in, so folding the reconciliation into it would skip precisely the population that needs it.
• Best-effort, like the level lift: a failure is logged rather than turning a durable registration into a 500. It does not self-heal — the log says so explicitly and asks for manual reconciliation, because an already-wedged account does not come back through this path (see Scope below).

Scope: prevents the wedge, does not cure it

This runs when a registration request arrives. An account that is already wedged does not come back through here on its own — for a wallet with a Completed registration getRegistrationInfo answers AlreadyRegistered, and the client then goes straight to the KYC step flow without re-posting register/complete. Such an account is only reached if it registers a further wallet.

The pre-existing backlog is small enough to handle out of band rather than with a data migration, and one of the affected accounts is the rejection shape above, which must not be auto-completed.

Not a behaviour change

The API already asserts the personal data is satisfied by granting LEVEL_20; the open step contradicts a decision the API itself made. No level is granted, no verification requirement changes — Ident and everything above it are untouched. The code path is reachable only through POST /v1/realunit/register/complete.

Verification

• 16 new tests. Each guard mutation-checked — neutralised body, accepting non-pending steps, dropping the isDataComplete guard, dropping the failed-chain guard, widening it back to “any failed step”, dropping the result discrimination, picking the pending step by first match instead of highest sequence, dropping the own-chain scoping, reading the verdict as isFailed instead of isRejected, and reverting each of the three call sites individually — every mutation turns the suite red.
• kyc + user + realunit subdomains green (785 passed), tsc --noEmit clean, eslint and prettier clean.

[Danswar]

Four review passes were needed to reach zero findings.

Pass 1 — the guard matched a PersonalData step that restartStep had deliberately re-opened after a Sumsub PROBLEMATIC_APPLICANT_DATA rejection, and would have re-completed it with the same rejected data, skipping the correction step. Also: the RealUnit spec provided KycService as a bare object, so the new call was an undefined-function TypeError swallowed by the best-effort catch — the call sites were unpinned and an existing assertion had stopped discriminating.

Pass 2 — the "self-heal on retry" claim was wrong and was removed from the log message, the comments and the PR body: an already-wedged account answers AlreadyRegistered and never re-posts register/complete, so this prevents the wedge rather than curing it.

Pass 3 — CANCELED was being read as proof a rejection had been remedied. It is not: initiateStep cancels a merely pending step as readily as a completed one. Remediation is now read from result, which cancel() preserves and a never-completed step never has.

Pass 4 — merged-in rows (negative sequence) were still voting on the verdict and eligible for closing; the chain is now scoped to the account's own steps. And a completion revoked by restartStep keeps its stale result, so the durable RESTARTED_STEP marker — not the status — is what keeps it blocking.

Every guard is mutation-checked in both directions: too broad and too narrow each turn the suite red.