Torna o volume da Railway gravável pela aplicação (#17)

/rails/storage é montado pertencendo ao root, mas a aplicação roda como
uid 1000: nunca conseguiu escrever ali. É a causa raiz das imagens de
produto respondendo 404 (anexos no banco, volume vazio) e do EACCES que
derrubou o boot quando o seed passou a escrever de fato.

O container passa a iniciar como root apenas para ajustar o dono do mount
e larga o privilégio em seguida com setpriv. Nada da aplicação roda como
root — nem db:prepare, nem db:seed, nem o servidor.

Escolhas:

* setpriv em vez de gosu: já vem do util-linux na imagem base (verificado
  em ruby:3.3.11-slim), então não adiciona pacote. su/runuser abrem shell
  intermediário e complicam sinal e código de saída.
* `exec` preserva o PID 1, mantendo o SIGTERM do shutdown chegando ao
  Rails.
* chown sem -R: basta o ponto de montagem, porque o Active Storage cria os
  subdiretórios e diretório novo herda o dono de quem o criou. Um -R
  ficaria lento a cada boot com o volume cheio.
* a guarda de uid torna o entrypoint reentrante — depois do exec ele roda
  como uid 1000, cai fora do bloco e segue o fluxo normal.

Verificado em Docker, reproduzindo a condição da Railway com uma volume
pertencente ao root (a volume nomeada precisa ter conteúdo, senão o Docker
a repovoa a partir da imagem e reescreve o dono, o que mascarava o teste):
sem a correção, Permission denied; com ela, a aplicação sobe como uid
1000, o seed grava os 20 blobs e a imagem de produto responde 200. PID 1 e
SIGTERM conferidos.

Contrapartida: o container inicia como root por instantes, mais privilégio
do que hoje. A aplicação segue sem root, que é o que o USER 1000:1000 do
Dockerfile do Rails 8 protege.


Claude-Session: https://claude.ai/code/session_017jSiuhB3mDxcty3rpck6jD

Co-authored-by: Uriel Juliatti <urieljuliatti@iMac-de-Uriel.local>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>