C2(migrate-immich-to-ringtail): plan correct extension-verification on immich-pg-on-ringtail card

CNPG's bootstrap.initdb.postInitSQL runs against the postgres
superuser database, not the application database. Extensions
declared there end up in the postgres db, not the immich db. The
Immich app installs them in its own database at startup.

This matches the existing minikube cluster's behavior — same
Cluster CR, same effect. Adjusting the card's verification to
reflect reality rather than (incorrectly) requiring extensions to
be present in the immich db pre-app-deploy.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/how-to/immich/immich-pg-on-ringtail.md

@@ -42,9 +42,20 @@ data. **No data import yet** — that's [[immich-pg-data-migration]].
 ## Verification
 
 - Cluster reaches `Ready`.
-- `psql` can connect via the app role and CREATE EXTENSION shows
-  `vchord`, `vector`, `cube`, `earthdistance` already installed.
-- `borgmatic` role exists with `pg_read_all_data` membership.
+- `borgmatic` role exists, `rolcanlogin=t`, and is a member of
+  `pg_read_all_data` (via `managed.roles[].inRoles`).
+- ExternalSecret `immich-pg-borgmatic` syncs from 1Password
+  (`Ready: True`) and the rendered Secret has `username=borgmatic`.
+- The `vchord`, `vector`, `cube`, `earthdistance` extensions show
+  installed in the `postgres` database (`\dx` from
+  `psql -U postgres`). They are NOT installed in the `immich`
+  database at this point — `postInitSQL` in CNPG's `initdb` block
+  runs against the `postgres` superuser database. The Immich app
+  itself creates the extensions in its own `immich` database at
+  startup; do not be alarmed by their absence pre-immich-deploy.
+  The `vchord.so` library is preloaded via
+  `shared_preload_libraries` regardless, so `CREATE EXTENSION` at
+  app startup just registers it in the right database.
 
 ## Borgmatic implications