Capture the pre-migration snapshot from 0.15.x, and stop claiming counts match when none were compared

Found by running preflight against a real Stalwart 0.15.5 in a VM. Two
defects, the second worse than the first.

1. AccountSnapshot could not read the version this tool migrates FROM.
   0.15.5 advertises no urn:stalwart:jmap capability and POST /api returns
   404 - the JMAP management API and x:Account are 0.16 features. 0.15.x
   exposes a REST API at GET /api/principal instead. So preflight's
   account-snapshot check warned and moved on, and every run against a real
   source instance had no "before" data at all.

   AccountSnapshot now dispatches on the capability the session document
   advertises - a positive signal, not an inference from a failed call -
   and internal/stalwartapi/principal.go implements the 0.15.x REST path,
   including its 1-based page/limit pagination so an install larger than
   one page isn't silently truncated.

2. With no "before" counts, the content-integrity comparison iterated an
   empty map, checked nothing, and reported "all message counts match".
   That is the strongest claim this tool makes - ARCHITECTURE 4.7 calls it
   the actual no-data-loss guarantee - made vacuously, and it would have
   passed on a migration that lost every message.

   The comparison now derives its account set from whatever the source
   could report, verifies every account and domain survived either way, and
   carries MessageCountsCompared so the report says plainly "MESSAGE COUNTS
   NOT COMPARED ... no-data-loss is NOT verified here" rather than implying
   otherwise.

What can and cannot be checked across the 0.15/0.16 boundary, now that a
real server has answered: 0.15.x has no per-mailbox message count at any
endpoint, and the impersonation login 0.16 offers returns 401 there, so
before/after message counts are impossible for the boundary migration this
tool exists for. Both versions do report per-account used quota (usedQuota
in 0.15's REST list, usedDiskQuota on 0.16's x:Account), so that is
captured on both sides. It is recorded and reported, not asserted on:
4.5 notes the 0.16 migration resets quotas to zero pending recalculation,
so comparing those bytes across the boundary would be a false alarm
generator.

Test servers across preflight, validate and stalwartapi now advertise
urn:stalwart:jmap, since they stand in for 0.16 instances and that
capability is what says so.

Verified end to end against the smoke VM: all nine preflight checks pass,
and the checkpoint records 2 accounts, 1 domain and per-account used quota
where it previously recorded nothing.

internal/checkpoint/types.go

@@ -74,13 +74,19 @@ type MailboxCount struct {
 // which the validate phase later compares against the migrated instance.
 // See ARCHITECTURE.md §4.1 and §4.7.
 type PreflightSnapshot struct {
-	TakenAt          time.Time                 `json:"taken_at"`
-	AccountCount     int                       `json:"account_count"`
-	Domains          []string                  `json:"domains,omitempty"`
-	MailboxCounts    map[string][]MailboxCount `json:"mailbox_counts,omitempty"` // account -> mailboxes
-	DKIMFingerprints map[string]string         `json:"dkim_fingerprints,omitempty"`
-	TLSFingerprints  []string                  `json:"tls_fingerprints,omitempty"`
-	ListenerPorts    []int                     `json:"listener_ports,omitempty"`
+	TakenAt       time.Time                 `json:"taken_at"`
+	AccountCount  int                       `json:"account_count"`
+	Domains       []string                  `json:"domains,omitempty"`
+	MailboxCounts map[string][]MailboxCount `json:"mailbox_counts,omitempty"` // account -> mailboxes
+	// UsedQuota is each account's used storage in bytes. It is the only
+	// per-account content measure available on both sides of the 0.15/0.16
+	// boundary - 0.15.x exposes no per-mailbox message counts at all - so
+	// it is what the post-migration comparison can actually assert on a
+	// boundary migration. See stalwartapi/principal.go.
+	UsedQuota        map[string]int64  `json:"used_quota,omitempty"`
+	DKIMFingerprints map[string]string `json:"dkim_fingerprints,omitempty"`
+	TLSFingerprints  []string          `json:"tls_fingerprints,omitempty"`
+	ListenerPorts    []int             `json:"listener_ports,omitempty"`
 }
 
 // Topology records how this Stalwart instance is deployed, as detected