Masked email: rewrite to the owner at RCPT TO, create responses carry the address, admins query all masks (ME-4, ME-9, ME-13, ME-19)

Found by running system_tests, which masked email no longer stops:
- rcpt_resolve rewrites a live mask to its owner's address, so
  Delivered-To names the account; delivery recognizes the mask from the
  original recipient when it belongs to that account.
- x:MaskedEmail/set create responses carry the server-set email.
- x:MaskedEmail/query returns every mask to a server-level impersonate
  holder, and filters on accountId.
- The refusal for an unlinked emailDomain uses upstream's wording.
- The shared delivery test checks the fork's address format (ME-13).
- The masked email test's tenant domain uses manual DKIM, so its cleanup
  leaves nothing behind.

docs/spec/features/masked-email.md

@@ -303,8 +303,16 @@ upstream files carry hooks marked `inbuxa:`. Acceptance tests 1 to 11 pass as
   - Creating an account or alias doesn't consult the mask index, so an
     account could be given an address a mask holds; the account then wins
     delivery. A random 12-character mask address makes this unlikely.
-  - The `x:` API's create response carries only the new id, as upstream's
-    registry responses do. The address is read with `/get`.
+  - At `RCPT TO` a live mask is rewritten to its owner's address, as
+    upstream's shared tests expect, so `Delivered-To` names the account
+    (ME-9). Delivery recognizes the mask from the original recipient
+    (`ORCPT`) when that mask belongs to the recipient. A sender who knows a
+    mask can set that `ORCPT` on mail to the owner's own address, which at
+    most files its own mail to Trash (through a disabled mask) or adds a header
+    naming the mask.
+  - Upstream's shared delivery test expected a `.` in a generated address.
+    ME-13 deliberately differs, so that one assertion checks the fork's
+    format instead, marked `inbuxa: ME-13`.
 
 ## Observed