Tenho informações adicionais caso ajudem a mitigar o problema do lado do Discourse. Minha instância (DigitalOcean ~1GB droplet com 2GB de swap) recentemente começou a demorar significativamente mais para reconstruir e relatar o mesmo erro fatal cerca de 3 em cada 4 vezes (a sorte parece melhorar após executar ./launcher cleanup, mas não tenho tamanho de amostra suficiente para confirmar isso).
Pouco antes do erro de falta de memória heap, estas linhas são registradas:
Node.js heap_size_limit (491.0) é menor que 1024MB. Definindo --max-old-space-size=1024.
Node.js heap_size_limit (491.0) é menor que 2048MB. Desabilitando a paralelização do Webpack com JOBS=0 para conservar memória.
Estou fora do meu domínio aqui, então peço desculpas se eu errar algo. Alguma pesquisa rápida indica que o ember-cli depende do node.js, que é por isso que acho que isso é relevante. O sinalizador --max-old-space-size pode potencialmente ser definido mais alto que a RAM (ele apenas entraria no espaço de swap, o que, como mencionado, está bom para este caso), então talvez 1024 seja um teto artificial que estamos atingindo contra o qual as reconstruções do Discourse não podem mais ser contidas.
Notas paralelas: aparentemente --optimize-for-size é um sinalizador do node.js que ajuda a reduzir o uso de memória (não tenho certeza se está sendo usado pelo Discourse/ember, talvez já esteja), e há uma anedota por aí de que o coletor de lixo não está ativado para certos usos do node.js, o que pode ser um problema.
Se algo disso for relevante e controlável do lado do Discourse do uso do ember/node.js, pode valer a pena alguém investigar. Se não, sem problemas, farei a solução temporária de upgrade de 2GB proposta acima. 