fix(deploy): the caddy override belonged under services, not networks #5567

main has been undeployable since #5565 merged

Both deploys since died in about a second:

BUILD FAILED for d8f8f0c... — previous release kept running, nothing switched
BUILD FAILED for ef45a754... — previous release kept running, nothing switched

Not a build failure — an invalid compose file. The caddy block was appended to the end of scripts/docker-compose.coolify-override.yml, below the top-level networks: key, so compose read it as a network named caddy carrying a profiles key and rejected the file. The indentation looked right; indentation does not say which section a key belongs to.

The guard passed anyway, which is the worse half

The test shipped with #5565 asserted:

expect(yaml).toMatch(/^\s{2}caddy:/m);   // "text at two-space indent, somewhere"

That matches perfectly with caddy in the wrong section. CI went green on a file that could not be parsed.

It is now structural: the file is split into top-level sections and the assertions name the section —

• caddy MUST appear under services:
• caddy MUST NOT appear under networks:
• networks: is pinned to exactly ["coolify"], so a stray key landing there fails instead of passing unnoticed

Verified by mutation, not by assertion alone: reintroducing the original layout fails both new tests; restoring the fix passes 26.

What worked

Nothing shipped broken. Build-first ordering kept the previous release running, the health gate never let a bad container take traffic, and production stayed 200 on f88fdfc throughout. FAILED_MARKER stopped the timer retrying the same doomed sha every 60s. The deploy path behaved exactly as designed — the change was wrong, and it was caught by the machinery built for it.

No manual marker clearing is needed: the marker pins one sha, so this new commit supersedes it.