Do not call it data loss when the instance would not show us the accounts

The dress rehearsal reported MISSING ACCOUNT [email protected] after a
migration that lost nothing: SMTP on the migrated instance accepts mail for
it, while an address that does not exist is refused, so the account is there.

Enumeration is permission-scoped. The "before" snapshot was read by an
account with full rights; the "after" snapshot by one whose admin role the
migration had not carried across - proven one step earlier, where the quota
rebuild was refused as unauthorised. It was shown a fraction of the accounts
and the comparison called the remainder lost.

"Missing" and "not permitted to see" are different findings and only one of
them is about the data. When the migrated instance shows fewer accounts than
existed, the result now says COULD NOT VERIFY and names the reader, rather
than asserting a loss the evidence does not support. It still fails the run:
an unverified migration is not a verified one, and the fix is to re-check
with an admin account, which --resume makes cheap.

Counting accounts is not a strong enough signal to tell the two cases apart,
so it does not try to - it reports the ambiguity instead of guessing.

Also fixes the test fake, which ignored ?types= and returned domains as
individuals, making every account count in these tests wrong.

internal/validate/content_integrity.go

@@ -41,6 +41,11 @@ type ContentIntegrityResult struct {
 	MessageCountMismatches []MailboxDelta // present both before and after, but with a different message count
 	MissingDomains         []string       // present before, absent after
 	MessageCountsCompared  bool           // false when the source version could not report counts
+	// AccountsVisibleAfter is how many accounts the migrated instance was
+	// willing to show whoever asked. An account without management
+	// permission is shown far fewer than exist - so a short list is a
+	// statement about the reader, not about the data.
+	AccountsVisibleAfter int
 }
 
 // OK reports whether everything that must match did: no account and no mail
@@ -64,6 +69,20 @@ func (r ContentIntegrityResult) DomainsOK() bool {
 	return len(r.MissingDomains) == 0
 }
 
+// Inconclusive reports that the migrated instance showed fewer accounts than
+// existed before, which makes any "missing" finding unsafe to believe.
+//
+// Enumeration is permission-scoped: an account that authenticates but holds
+// no management role is shown only what it may see, and a v0.16 migration
+// does not always carry an admin role across - so the account that read the
+// "before" side may not have the same reach afterwards. Observed on a clone
+// of production: every account survived, and the comparison called one of
+// them lost because the reader could no longer see it. Reporting data loss
+// on that evidence is worse than reporting nothing.
+func (r ContentIntegrityResult) Inconclusive() bool {
+	return len(r.MissingAccounts) > 0 && r.AccountsVisibleAfter < r.AccountsChecked
+}
+
 func (r ContentIntegrityResult) String() string {
 	var b strings.Builder
 	if r.MessageCountsCompared {
@@ -140,6 +159,8 @@ func compareContentIntegrity(ctx context.Context, client *stalwartapi.Client, be
 		afterAccounts[a] = true
 	}
 
+	result.AccountsVisibleAfter = len(afterAccounts)
+
 	for _, d := range before.Domains {
 		if !containsDomain(after.Domains, d) {
 			result.MissingDomains = append(result.MissingDomains, d)