fix(docker): instala gems faltantes no boot (bundle check || bundle install)

O bundle fica no volume nomeado bundle_cache, que sombreia os gems da
imagem — adicionar uma gem (ex.: caxlsx) causava Bundler::GemNotFound ao
subir, mesmo com --build, pois o volume persistente não recebe os gems
novos. Rodar bundle install no boot resolve de forma idempotente.

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

docker-compose.yml

@@ -32,7 +32,12 @@ services:
     # O passo do cron é "best-effort": se o crontab/cron não estiver disponível
     # (ex.: imagem antiga sem o pacote `cron`), apenas avisa no log e SEGUE —
     # nunca impede o Rails de subir. (Requer rebuild: docker compose up -d --build)
-    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails db:prepare && { bundle exec whenever --update-crontab && cron || echo '[boot] AVISO cron/crontab indisponivel (rode com --build), seguindo sem agendamento'; } && bundle exec rails s -b 0.0.0.0"
+    # `bundle check || bundle install`: os gems ficam num VOLUME nomeado
+    # (bundle_cache) que persiste e SOMBREIA os gems da imagem — então adicionar
+    # uma gem nova ao Gemfile não chega no container só com `up`/`--build`. Este
+    # passo instala o que faltar no volume no boot (idempotente e rápido quando já
+    # está tudo instalado), evitando o Bundler::GemNotFound ao subir.
+    command: bash -c "rm -f tmp/pids/server.pid && (bundle check || bundle install) && bundle exec rails db:prepare && { bundle exec whenever --update-crontab && cron || echo '[boot] AVISO cron/crontab indisponivel (rode com --build), seguindo sem agendamento'; } && bundle exec rails s -b 0.0.0.0"
     # O banco PostgreSQL já existe externamente.
     # Configure DB_HOST no .env com o IP/hostname do seu servidor PostgreSQL.