Stop a clean migration reporting domains it never lost

The post-migration comparison had the two versions counting domains
differently, and yesterday's wiring turned that into a gate: `run` would have
failed a migration that lost nothing.

The 0.15 side added every domain appearing in any account's address on top of
the domain principals - the fallback's own comment says "if the instance has
no explicit domain principals", but the loop ran unconditionally. The 0.16
side did the reverse, listing only domains some account calls its primary,
discarding the full Domain list it had already fetched. An instance with
three declared domains and accounts aliased across nine reported nine before
and three after. INBUXA is exactly that shape, and this was the account/domain
over-count noted as undiagnosed.

Both sides now mean "the domains this server holds". A domain that still goes
missing is reported as a warning rather than failing the run: what the two
versions call a domain differs across this boundary in ways we have now been
caught by once, and a missing account - which is compared with a local-part
fallback and is what actually matters - still fails.

Narrowing OK() also made String() return before printing the domain lines,
so the new warning would have been silent. Caught by its own test.

internal/validate/content_integrity.go

@@ -43,11 +43,25 @@ type ContentIntegrityResult struct {
 	MessageCountsCompared  bool           // false when the source version could not report counts
 }
 
-// OK reports whether everything this comparison was able to check matched.
-// Read it together with MessageCountsCompared: OK with that false means
-// "the directory survived", not "no mail was lost".
+// OK reports whether everything that must match did: no account and no mail
+// went missing. Read it together with MessageCountsCompared: OK with that
+// false means "the directory survived", not "no mail was lost".
+//
+// Domains are deliberately not part of this. What the two versions call a
+// domain differs across the 0.15/0.16 boundary — principals on one side,
+// Domain objects on the other, with aliases and account-less domains
+// counted differently — and we have already been caught once reporting a
+// migration that lost nothing as having lost domains. A disagreement there
+// is worth showing an operator; it is not worth failing a migration over,
+// where a missing account is.
 func (r ContentIntegrityResult) OK() bool {
-	return len(r.MissingAccounts) == 0 && len(r.MessageCountMismatches) == 0 && len(r.MissingDomains) == 0
+	return len(r.MissingAccounts) == 0 && len(r.MessageCountMismatches) == 0
+}
+
+// DomainsOK reports whether every domain seen before the migration is still
+// listed after it.
+func (r ContentIntegrityResult) DomainsOK() bool {
+	return len(r.MissingDomains) == 0
 }
 
 func (r ContentIntegrityResult) String() string {
@@ -59,7 +73,10 @@ func (r ContentIntegrityResult) String() string {
 			"(this migration's source version reports no per-mailbox counts, so no-data-loss is NOT verified here - "+
 			"only that every account and domain survived)", r.AccountsChecked)
 	}
-	if r.OK() {
+	// Everything below is a finding, so return early only when there is
+	// nothing at all to report - domains included, even though they no
+	// longer fail the run. A warning nobody can read is not a warning.
+	if r.OK() && r.DomainsOK() {
 		if r.MessageCountsCompared {
 			b.WriteString(", all message counts match")
 		}