Deploy: remote_nginx lost REMOTE_OUT to a subshell, 5c refuses to edit a conf without a 2b backup, and the dry-run suite runs in CI

[Apolloccrypt]

Vervolg op #376: twee bevindingen van de reviewer, een documentatie-nit, en een
bug die deploy-run 4 stilzette.

0. Run 4 stopte in 2b op een meting die de server wel degelijk had gedaan

Run 4 (TS 20260903-0216, deploy/logs/deploy-3.1-20260903-0216.log) stopte met

STOP .env backup is a real file with content -- the server never printed 'after .env backup bytes'

terwijl de server die regel wel printte (1420 bytes) en beide confs had
opgelost, paramant.conf op 14682 bytes. De meting klopte; het script kon hem
niet zien.

De wrapper uit #376 was een pipeline:

remote_nginx() { { printf '%s\n' "$NGINX_RESOLVE_SNIPPET"; cat; } | remote "$@"; }

Elke stage van een pipeline is een subshell, dus remote() en _remote_run()
zetten REMOTE_OUT en REMOTE_RC in een kind dat daarna afsloot. In de parent
stond nog wat het vorige remote-blok had achtergelaten, dus elke expect na een
remote_nginx-aanroep beoordeelde de verkeerde uitvoer, en een niet-nul
REMOTE_RC uit zo'n blok zou de deploy helemaal niet gestopt hebben.

remote_nginx leest de body nu zelf en geeft remote() zijn stdin via een
redirect (< <(printf ...)), dus remote() draait in de aanroepende shell en
beide variabelen landen waar de asserts kijken.

Op de server heeft run 4 alleen rollback-tags en backups gemaakt. Geen
container hercreeerd, geen conf bewerkt, geen docroot geschreven.

1. 2b en 5c resolven onafhankelijk, dus ze kunnen het oneens zijn

Dat onafhankelijk resolven is met opzet: elke fase vraagt de server wat er op
dat moment in sites-enabled staat. Maar fase 3 en 4 (pull, build, recreate)
zitten ertussen. Wijzigt sites-enabled in dat venster, dan bewerkt 5c een conf
die 2b nooit heeft geback-upt. Elke FATAL in 5c roept restore() aan, en die
kon alleen terugzetten wat gefiled was.

Aangetoond op de oude code, met een replica waar 2b paramant-live.conf filede
en 5c daarna paramant.conf oploste:

FATAL ... Restoring the backed up confs.
available/paramant-public.conf: OK
available/paramant.conf: FAILED

Public hersteld, backend LEFT MODIFIED, terwijl de tekst een volledig herstel
belooft.

Fix. 5c eist per resolved naam [ -f "$NGBK/$name.pre-3.1-$TS" ] vóór de
eerste sed, telt ze in before confs without a backup, en STOPt met een FATAL
die de conf en het gezochte backup-pad noemt. Een run die daar stopt heeft niets
geschreven. De deploy assert lokaal dat de teller nul is. restore() loopt nu
over $RESOLVED_CONFS in plaats van te globben over de backup-map, dus wat het
terugzet is precies wat bewerkt is, en het zegt per conf wat het terugzette.

2. De dry-run-suite draaide nergens

docs/ONBOARDING.md:51 zei het letterlijk: "exists but runs in no workflow".
Een groene PR zei dus niets over het enige script in deze repo dat
productiecontainers hercreëert, en twee rondes nginx-wijzigingen zijn op die
stilte geland.

Toegevoegd als job deploy-dryrun in .github/workflows/test.yml: bash, geen
server, geen secrets, checkout gepind op dezelfde SHA als de andere jobs.
ONBOARDING is op beide regels gecorrigeerd.

Nog niet in de required contexts. Zoals afgesproken: pas toevoegen nadat hij
drie keer groen op main heeft gedraaid. De branch-protection regel je zelf.

Bijvangst: ubuntu-latest heeft shellcheck, dus de shellcheck-poot van de suite
draait daar wel en op een laptop zonder shellcheck niet. Lokaal met shellcheck
0.11.0 erbij: shellcheck -S error schoon op beide bestanden.

3. Documentatie-nit

#376 zei dat fase 6 de opgeloste naam gebruikt. Dat klopt niet. Fase 6 leest
nginx -T, de geladen config, en probet de site over HTTP; geen van beide weet
hoe het bestand op schijf heet. DEPLOY-3.1.md zegt dat nu, met de correctie
erbij benoemd. Het commit-bericht van #376 is gemerged en niet meer te wijzigen.

Bewijs

bash tests/deploy-3.1-dryrun.test.sh: 259 checks groen, was 239. Nieuw:

• 6i-8 de wrapper zelf: remote_nginx() wordt echt aangeroepen met een
  gestubde _remote_run die REMOTE_OUT zet, na REMOTE_OUT en REMOTE_RC
  eerst met muffe waarden te hebben gevuld. Asserts: de caller ziet de nieuwe
  waarden, de snippet staat voor de body in de stdin die de stub kreeg, en de
  body komt heel aan. De pipe-vorm blijft als negatieve controle in de test, dus
  de check kan niet slagen op een harness die de bug zou doorlaten. Plus een
  grep die elke remote-aanroep rechts van een pipe weigert. De bloktests
  extraheren heredoc-bodies en raken de wrapper niet; daarom miste 252 groene
  checks dit

• 6i-7 rename tussen 2b en 5c: 5c exit niet-nul, FATAL noemt
  paramant.conf.pre-3.1-..., before confs without a backup = 1, en beide
  confs zijn md5-identiek aan voor de run, dus niets blijft bewerkt achter. Ook:
  de run belooft geen restore meer die hij niet kan waarmaken

• 6i-7b controle: dezelfde fixture met de backup wél op de opgeloste naam
  loopt schoon door en bewerkt beide confs

• 6i-7c een FATAL ná de edits zet beide resolved confs terug, byte voor
  byte, en meldt per conf wat het terugzette

• elke 5c-fixture seedt nu eerst de 2b-backups, wat een echte run ook gedaan
  heeft tegen de tijd dat 5c start

Sabotage, twee keer. De preconditie eruit en restore() terug naar de glob:
7 checks rood, waaronder "5c changed a conf before it stopped" en "5c edited a
conf that has no backup". De wrapper terug naar de pipe-vorm: 3 checks rood,
"REMOTE_OUT did not reach the caller", "REMOTE_RC did not reach the caller (got:
[7])" en de pipe-grep. Beide teruggezet, 259 weer groen.

Verder groen: tests/static-sanity.sh PASS, scripts/check-test-declarations.sh
(114 suites), scripts/check-commit-style.sh, shellcheck -S error.