docs: clarify why docker compose avoids the pgvector privilege error

The previous wording pinned the claim entirely on database/init.sql,
which only runs on first boot of an empty data volume. The load-bearing
reason is that the bundled stack connects as the postgres superuser, so
it can create the extension regardless of volume state. Name that first
and keep init.sql as the secondary reason.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/v3/contributing/troubleshooting.mdx

@@ -216,7 +216,7 @@ CREATE EXTENSION IF NOT EXISTS vector;
 
 The `IF NOT EXISTS` calls then short-circuit and the application role needs no extension privileges. This is the supported path for deployments where the platform, not the application, owns extension management.
 
-You won't hit this with `docker compose` — the bundled database service runs `database/init.sql` as an initdb script, which creates the extension before Honcho ever connects. It comes up on managed Postgres, Kubernetes operators, and other setups where you bring your own database and its role is deliberately not a superuser.
+You won't hit this with `docker compose` — the bundled stack connects as `postgres`, a superuser, and its database service also creates the extension from `database/init.sql` on first boot. It comes up on managed Postgres, Kubernetes operators, and other setups where you bring your own database and its role is deliberately not a superuser.
 
 ## Cache & Redis