fix(kyc): let compliance accounts reach an identification again

[Blume1977]

The problem

A Compliance account currently has no reachable path to a verifiedName, and since the staff-clearance rule (#4395 → #4572) an account without one is refused every elevated endpoint. Two guards from #3577 close both doors:

1. kyc.service.ts rejected every KYC call for a Compliance account (KYC not allowed for compliance accounts) — so the "Start KYC" button the staff-clearance screen offers (services#1233) always ended in a raw error.
2. UserData.checkIfMergePossibleWith blocked every merge involving a Compliance account — so entering the mail address of one's own already-identified account produced Account already exists and no merge request, because isMergePossibleWith returned false.

#3577 predates the clearance rule; the two protections were never reconciled. The result is a permanent lockout that only an operator-run migration can lift (#4574, #4590, #4596 are three such one-off backfills in three days).

What changed

• KYC is no longer refused for Compliance accounts. They run the same identification as everyone else, which is exactly what the staff-clearance screen and docs/staff-kyc-clearance.md describe as the identity-verified path.
• The merge block is scoped to what it was for. checkIfMergePossibleWith(slave, isMailMerge) keeps the block absolute for the merges the system derives on its own (MergeReason.IBAN, MergeReason.IDENT_DOCUMENT) and lifts it only for MergeReason.MAIL — the merge the account owner triggers by entering an address and completes by opening a link delivered to the other account's mailbox, so the same person demonstrably controls both sides.
• The flag is derived from the reason in sendMergeRequest and carried through executeMerge → mergeUserData, because the check runs a second time against freshly loaded entities at confirmation time.
• Every other merge condition (verified-name mismatch, AML list, blocked, account type, already merged) is untouched and still applies on the mail path.

Checks

• New spec compliance-merge-exemption.spec.ts: block holds by default in both directions, exemption applies on the mail path only, name-mismatch still throws, non-compliance accounts unaffected.
• account-merge.service.spec.ts: the reason→flag derivation is pinned for MAIL/IBAN/IDENT_DOCUMENT on both the request and the execution side (a hard-coded true or false fails).
• account-merge.processing.spec.ts assertion updated to the new signature.
• Full suite: 360 suites / 6854 tests pass. Prettier, ESLint, tsc --noEmit clean.

Note

This lifts part of a protection added in #3577, whose PR description carries no rationale beyond the release checklist — @davidleomay should confirm the narrowed scope still covers what it was written for. With this change, #4596 (the pending one-off backfill) becomes a convenience rather than the only way out, and the dead-end handling in services#1246 is no longer needed.