Tengo información adicional en caso de que ayude a mitigar el problema desde el lado de Discourse. Mi instancia (DigitalOcean ~1GB droplet con 2GB de swap) recientemente comenzó a tardar significativamente más en reconstruirse y a reportar el mismo error fatal aproximadamente 3 de cada 4 veces (la suerte parece mejorar después de ejecutar ./launcher cleanup, pero no tengo suficiente tamaño de muestra para confirmarlo).
Poco antes del error de falta de memoria heap, se registran estas líneas:
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
Estoy fuera de mi dominio aquí, así que me disculpo si digo algo incorrecto. Una investigación rápida indica que ember-cli depende de node.js, que es por lo que creo que esto es relevante. El flag --max-old-space-size puede ser configurado más alto que la RAM (simplemente iría al espacio de swap, lo cual como se mencionó está bien para este caso), así que quizás 1024 es un techo artificial que estamos golpeando contra el cual las reconstrucciones de Discourse ya no pueden ser contenidas.
Notas al margen: aparentemente --optimize-for-size es un flag de node.js que ayuda a reducir el uso de memoria (no estoy seguro si es utilizado por Discourse/ember, quizás ya lo es), y hay una anécdota por ahí de que el recolector de basura no está activado para ciertos usos de node.js, lo cual podría ser un problema.
Si algo de esto es relevante y controlable desde el lado de Discourse del uso de ember/node.js, podría valer la pena que alguien lo investigue. Si no, no se preocupen, aplicaré la solución temporal de actualización a 2GB propuesta anteriormente. 