Então está confirmado que o problema foi que, há alguns anos, quando tentei configurar o S3 pela primeira vez, defini enable_s3_uploads no banco de dados, o que faz com que a restauração não funcione porque ele tenta fazer upload para o S3, mas não tem informações suficientes. (Suspiro. Mas falha ao restaurar a instância multisite/s3 porque alguns arquivos “não foram migrados para o S3”.)
Eu me pergunto se faria sentido ocultar todas as configurações de upload do S3. Tenho certeza de que nada de bom pode vir de defini-las na UX. Mas pode ser útil definir os uploads do S3 no banco de dados. . . . talvez.
O que foi restaurado para a instalação padrão não está exibindo os uploads porque está fazendo o seguinte:
Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)
O caminho que ele está procurando é /var/www/discourse/public/default/original/1X/ em vez de /var/www/discourse/public/uploads/default/original/1X/
… . .
E isso ocorre porque fiz um remapeamento tentando corrigir as referências do bucket S3 e isso quebrou os caminhos nos URLs locais.
Acho que talvez isso seja muito detalhado para ser útil para alguém. Embora eu ainda pense que ocultar as variáveis de upload do S3 da UX seja uma boa ideia.