Separa migrations do boot do web, com uma etapa de release

[Hirley]

Fecha a #82.

bin/docker-entrypoint roda db:prepare antes do Puma toda vez que o container sobe. É o que faz docker compose up --build funcionar de primeira, e continua sendo o default — mas passou a ser desligável com DB_PREPARE_ON_BOOT=false, que é o que um deploy de verdade deve fazer, rodando as migrations numa etapa de release antes de subir as réplicas.

	Quando	Como
No boot (default)	docker compose up, docker run, demo de uma réplica	nada a fazer
Etapa de release	qualquer deploy real, obrigatório com mais de uma réplica	DB_PREPARE_ON_BOOT=false + migrations antes das réplicas

A premissa da issue precisava de correção

Ela falava em "todas as réplicas tentam preparar o banco ao mesmo tempo", sugerindo risco de corrupção. O schema nunca esteve em risco: as migrations do Rails pegam um advisory lock no Postgres — verifiquei em activerecord-8.1.3.1, Migrator#with_advisory_lock.

O que acontece de verdade é pior de um jeito diferente. O lock é obtido com pg_try_advisory_lock, que não bloqueia: quem perde recebe false e o Rails levanta ConcurrentMigrationError. Como o entrypoint roda com bash -e, o db:prepare que falha derruba o container — a réplica morre no boot em vez de subir depois da que migrou.

Somado ao acoplamento que a issue já apontava (boot preso no tempo e no sucesso da migration), esse é o argumento inteiro. Está escrito assim no entrypoint e no README, no lugar da versão imprecisa.

Duas decisões

O default continua ligado. Inverter deixaria o docker run documentado no README e o compose local subindo contra um banco vazio — um jeito pior de falhar do que o problema evitado. Quem faz deploy de verdade liga o modo release explicitamente, e a documentação diz isso.

A etapa de release não precisou de comando novo. O entrypoint só prepara o banco quando o comando é ./bin/rails server, então docker compose run --rm web ./bin/rails db:prepare já passa direto. Isso virou um passo do smoke test: sem ele, seria um caminho documentado que nada exercita — a mesma lacuna que o smoke test da #81 veio fechar para a imagem inteira.

Verificação

• a condição do entrypoint nas cinco combinações que importam (server com a variável vazia / true / false, db:prepare, bin/jobs) — só a primeira e a terceira preparam;
• docker compose config com e sem a variável, resolvendo para "" e "false";
• gates de sempre no container: RuboCop 110 arquivos / 0 ofensas, zeitwerk:check All is good!, RSpec 394 exemplos / 0 falhas.

O que não verifiquei localmente: o comportamento dentro do container. Exigiria rebuildar a imagem (~10 min nesta máquina, com o Docker Desktop já tendo caído duas vezes hoje), e o passo novo do smoke test roda exatamente isso no CI — que, aliás, é onde as duas últimas diferenças Windows/Linux apareceram.