wp-init: fail fast on wrong DB password, strict theme activation

- The 'Waiting for database' loop spun forever when the .env password did
  not match the db_data volume; it now aborts with exit 1 and explains how
  to recover (put the old password back; README 'Passwords' for a real
  change), plus a 5-minute timeout for a dead database.
- Theme presence is checked on disk instead of via wp-cli (which needs the
  database), activation is always attempted and fatal on failure, so the
  script can no longer delete the active theme and report success.
- README gains a 'Passwords' section documenting the correct password-change
  procedure (ALTER USER in the running DB, then .env).

README.md

@@ -152,6 +152,26 @@ Tudo o que é do usuário fica em **volumes**, não no container:
 
 `docker compose down` (sem `-v`) preserva tudo; só `down -v` recria do zero. Para pular atualizações numa reinicialização, use `WP_SKIP_UPDATES=1` no `.env`.
 
+### Senhas
+
+A senha do banco é gravada **dentro do volume `db_data` na primeira instalação**. Trocar `WORDPRESS_DB_PASSWORD` ou `MARIADB_ROOT_PASSWORD` no `.env` depois disso **não** atualiza o banco — o WordPress perde a conexão (`Error establishing a database connection`) e o setup aborta com erro em vez de reinstalar por cima.
+
+Para voltar ao normal, devolva a senha original no `.env` e reinicie (`docker compose up -d`).
+
+Para trocar a senha de verdade, altere-a nos dois lugares, nessa ordem:
+
+```sh
+# 1. No banco em execução (troque NOVA_SENHA pela senha nova):
+docker compose exec db mariadb -u root -p"$MARIADB_ROOT_PASSWORD" \
+  -e "ALTER USER 'wordpress'@'%' IDENTIFIED BY 'NOVA_SENHA'; FLUSH PRIVILEGES;"
+
+# 2. No .env:
+WORDPRESS_DB_PASSWORD=NOVA_SENHA
+
+# 3. Reinicie:
+docker compose up -d
+```
+
 ## Deploy
 
 O tema está preparado para deploy em ambientes WordPress padrão (VPS, shared hosting, WP Engine, Kinsta, etc.).