Fix three defects a full VM migration exposed

Ran a complete 0.15.5 -> 0.16.14 migration of the smoke VM, driving the
phases in the order the real pipeline will. It worked - all mail intact and
readable afterwards, all ten listeners up, cutover executed for the first
time ever and checkpoint resume exercised - and it exposed three defects.

1. The converted config was installed root-owned while the service runs as
   its own user. Stalwart crash-looped 28 times on "Failed to read data
   store settings: Permission denied", minutes after the mistake and
   nowhere near it. This is the same ownership trap that retired the
   rollback implementation, in a new place: writing files as root is the
   natural thing for a tool running as root to do, and it is wrong every
   time the service is not root.

   Cutover now installs the config itself, copying ownership and mode from
   the config being replaced.

2. v0.16.14 does not serve /api - the endpoint stalwartapi assumed.
   Confirmed against a fully migrated, fully configured, serving instance
   rather than a sandbox: /api, /api/principal and /jmap/ all 404. The JMAP
   endpoint is the one the session document advertises, which is what RFC
   8620 discovery is for.

   The client now discovers it, re-basing the advertised path onto the
   operator's host: a real instance advertises its canonical public URL
   ("https://mail.smoke.test/jmap/") which frequently isn't reachable from
   where this tool runs. The session is authoritative about the path; the
   operator is authoritative about the host.

3. Dispatching on the urn:stalwart:jmap capability was wrong, because
   NEITHER version advertises it - not 0.15.5, and not a fully migrated
   0.16.14. That sent 0.16 instances down the 0.15 REST path where every
   call 404s. The client probes what the instance actually serves instead.
   Less elegant than a declared capability, with the advantage of being
   true.

Also: a JMAP "forbidden" now explains itself. An account holding the admin
role before the migration was refused x:Account/query afterwards, and a
bare "forbidden" gives an operator nowhere to start. Whether the role
failed to carry or v0.16 wants different permissions was not isolated, and
that question is recorded as open - it gates quota recalculation and any
post-migration validation.

Verified against both live instances: the 0.15.5 reports 3 accounts and its
domain over REST, and the migrated 0.16.14 routes to JMAP, finds the right
endpoint, and returns the explained refusal.

ARCHITECTURE.md

@@ -672,12 +672,39 @@ happens to need them. `preflight.DeploymentKind` is a type alias for
   corpus has been through the converter. Everything in §4.9's rewrite and
   most of §8's newer entries came from that, not from reading code.
 
-  Still unproven against real software: **cutover** (never executed - its
-  unit rewrite, service control and quota recalculation are tested only
-  against fakes), the **`x:Task` quota wire format**, **systemd drop-in**
-  handling, and anything on a **non-RocksDB backend** or a **Docker**
-  deployment. Cutover is the gap that matters most, since it is the phase
-  that mutates production.
+  **Cutover has now run**, in a complete 0.15.5 -> 0.16.14 migration of the
+  smoke VM: binary verified and installed, the unit rewritten with its
+  hardening intact, service restarted, health check passed, and checkpoint
+  resume exercised. All mail survived and was readable afterwards. Three
+  defects came out of it and are fixed:
+
+  - The converted config was installed root-owned while the service runs as
+    its own user, so it crash-looped 28 times on "Permission denied". The
+    ownership trap that retired the rollback implementation (§4.8), in a
+    new place. Cutover now installs the config itself, copying ownership
+    and mode from the config being replaced.
+  - **v0.16.14 does not serve `/api`.** Confirmed against a fully migrated,
+    fully configured instance, not just a sandbox: `/api`, `/api/principal`
+    and `/jmap/` all 404, and the JMAP endpoint is the one the session
+    document advertises. The client now discovers it, re-basing the
+    advertised path onto the operator's own host - a real instance
+    advertises a canonical public URL that frequently isn't reachable from
+    where this tool runs.
+  - Dispatching on the `urn:stalwart:jmap` capability was wrong, because
+    *neither* version advertises it. The client probes what the instance
+    actually serves instead.
+
+  Still unproven: the **`x:Task` quota wire format** (the endpoint fix makes
+  it reachable, but the migrated instance refused the call - below),
+  **systemd drop-in** handling, and anything on a **non-RocksDB backend**
+  or a **Docker** deployment.
+- **A migrated instance may have no working administrator.** An account
+  holding the admin role before migration was refused `x:Account/query`
+  afterwards with `forbidden`. Whether the role failed to carry or v0.16
+  requires different permissions was not isolated; the operator's position
+  is the same either way. The client now explains this rather than
+  reporting a bare "forbidden", but the underlying question is open and
+  gates both quota recalculation and any post-migration validation.
 - **Quota recalculation is grounded but unproven.** The `x:Task` wire
   format comes from Stalwart's schema reference rather than a live server;
   §4.5 lists exactly which two details are inferred. A smoke test against a