Specs: point a stock ihasmail at the migrated server afterwards

Asked for by John, 2026-09-19. Public ihasmail is Stalwart-facing and knows
nothing about INBUXA, so running an unmodified one against the migrated
server checks something the fork's own suites cannot: that a client written
for upstream still works.

Each difference it finds is one of two things, and the point is to say
which: a regression against upstream's contract, which the fork's tests
would not catch because they test the fork; or a feature that now expects
INBUXA's own front ends, which belongs in the contract and the release
notes rather than in a user's surprise.

After mail is flowing, not as a gate. It informs the contract; it doesn't
block a cutover.

docs/spec/migration.md

@@ -83,6 +83,19 @@ The same checks as `cutover.md`, run by the tool rather than by hand:
 A failed check is a failed migration, and the tool rolls back rather than
 leaving a half-migrated server for the operator to reason about at 2am.
 
+## After a migration: the stock client
+
+A migration that passes its own verification has proved the fork works for
+the fork. Pointing an **unmodified public ihasmail** at the migrated server
+proves something else: that a client which knows nothing about INBUXA still
+works against it. It runs anywhere — JMAP and OAuth over the network — and
+needs only an OAuth client it may use.
+
+Each difference it turns up is either a regression against upstream's
+contract or a feature that now expects INBUXA's own front ends. The tool
+doesn't run this; it belongs in the release notes and the contract
+(SPEC.md §5.2). It is named here so the first migration doesn't skip it.
+
 ## Rollback
 
 A first-class path, not an appendix.