Compat: what the recording holds, and what two of the tests now prove

record-compat.py ran against the live server as a server-level
administrator: 8 accounts, which matches the dashboard, so it reached all
of them. One tenant with its quotas and members; no masked addresses, no
archived items.

The empty files are right rather than short. INBUXA has no masked
addresses and retention is off, so masked_email_compat and undelete_compat
iterate an empty list: they pass without comparing anything, which is worth
saying plainly, because a green run from either would otherwise read as
evidence of compatibility. That puts them where scim_compat and
per_domain_directory_compat already sit.

So one recording carries weight, expected.json, and it is made. SPEC §7's
cutover steps 2 and 3 come down to the tenant, the domains and the
accounts until either feature is switched on.

docs/spec/SPEC.md

@@ -534,7 +534,10 @@ before anything that could prompt that notice happens.
 2. INBUXA's data opens in the fork on a copy: tenants, masked addresses,
    archived items, every account.
 3. Masked addresses already handed out still deliver; archived items still
-   restore.
+   restore. Moot as things stand: INBUXA has no masked addresses and
+   retention is off (2026-09-19), so steps 2 and 3 come down to the tenant,
+   the domains and the accounts. It applies again the moment either feature
+   is switched on (`compat-tests.md`).
 4. Cutover on the running host, with the Enterprise build kept for rollback.
 5. Only then: public repository and announcement, with the INBUXA fork of
    ihasmail released alongside. Public ihasmail stays Stalwart-facing (§5).