Fix two preflight defects a live production rehearsal found

Ran the rehearsal read-only against a live production instance. It
completed, and two preflight checks were wrong in ways a test instance
could not have shown.

1. Store-backend detection missed the config entirely. A config generated
   by `stalwart --init` declares `type = "rocksdb"` inside a
   `[store.rocksdb]` section, which is what every test fixture here used.
   The production config has no section headers at all and declares
   `store.rocksdb.type = "rocksdb"` flat. Detection only matched a bare
   `type` key, so it reported "no known store backend type found in config"
   and left topology.store_backend empty.

   That mattered more than a warning suggests: backup.Run treated an
   unrecognized backend as a *skip*, so a real run would have continued
   with no filesystem or database backup at all - the single artifact that
   phase exists to produce, quietly absent. Flat dotted keys are now
   detected, and an unrecognized backend is a hard failure rather than a
   skip.

2. The cluster warning didn't say where it matched. It fires on any
   occurrence of "cluster" anywhere in the config, which is the correct
   bias - a missed cluster corrupts a shared store - but on the production
   config the only match was inside the value of an unrelated setting,
   leaving a whole config to search to establish that. It now names the
   location and distinguishes a match in the setting name from one in its
   value.

Both verified against the real config: store-backend now reports
"rocksdb (store.rocksdb)", and the cluster warning names the setting,
making a false positive dismissible at a glance.

No production data is in this commit: the fixtures use example.com and the
flat-key shape only. Coverage numbers from that run matched the earlier
scrubbed-corpus measurement exactly.

ARCHITECTURE.md

@@ -698,6 +698,33 @@ happens to need them. `preflight.DeploymentKind` is a type alias for
   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.
+- **Rehearsal has been run against a live production instance**, read-only,
+  and found two preflight defects a test instance could not have:
+
+  - **Store-backend detection missed a flat config entirely.** A config
+    generated by `stalwart --init` declares `type = "rocksdb"` inside a
+    `[store.rocksdb]` section; the production config has *no section
+    headers at all* and declares `store.rocksdb.type = "rocksdb"` flat.
+    Detection checked only for a bare `type` key, so it found nothing and
+    left `topology.store_backend` empty - and `backup.Run` treated an
+    unrecognized backend as a *skip*, meaning a real run would have
+    proceeded with no filesystem backup whatsoever. Both fixed: flat keys
+    are detected, and an unrecognized backend is now a hard failure,
+    because the one artifact this phase exists to produce must not be
+    quietly absent.
+  - **The cluster warning didn't say where it matched.** It fires on any
+    occurrence of "cluster" anywhere in the config, which is the right bias
+    - a missed cluster is the dangerous direction - but on the production
+    config the sole match was inside the *value* of an unrelated setting.
+    The warning now names the location and says whether the match was the
+    setting or only its value, which turns a config-wide search into a
+    glance.
+
+  Also confirmed there: the HTTPS path works against a real certificate,
+  and the coverage numbers match the earlier scrubbed-corpus measurement
+  exactly (12,182 unmigrated). Account enumeration past one page is still
+  untested - that instance has six accounts, not the hundred-plus the
+  pagination loop exists for.
 - **A migrated instance has no working administrator - diagnosed and
   fixed.** `migrate_v016.py` assigns every migrated account the `User`
   role regardless of what it held before, so an account that was an