2fb1e62b2e
`_guard_named_profile_under_multiplexer` correctly refuses a named-profile gateway while the default gateway is multiplexing — starting a second one would double-bind that profile's platforms. The refusal is right; its exit code was not. The refusal is decided entirely by configuration (`multiplex_profiles` plus the allowlist), so it is permanent: no number of retries can change the answer. Exiting 1 made it look transient to a service manager. That matters because this module generates the systemd unit, and the template pairs `Restart=always` / `RestartSec=5` with `StartLimitIntervalSec=0` — it deliberately trades systemd's generic start-rate limiter for the specific `RestartPreventExitStatus=GATEWAY_FATAL_CONFIG_EXIT_CODE` backstop declared three lines below it. Returning 1 left that backstop unarmed with the limiter already disabled, so a correct, permanent refusal became an unbounded restart loop. Observed on a host running `multiplex_profiles: true` with a leftover per-profile unit: 136 refusals in ~13 minutes, stopped only by hand. `GATEWAY_FATAL_CONFIG_EXIT_CODE` (78, EX_CONFIG) is this codebase's existing answer for exactly this case — `gateway/restart.py` documents it as the fatal configuration error that the s6 finish script translates into 125 "permanent failure" (#51228). This adopts that contract rather than inventing one, so the fix also works on s6 hosts, not just systemd. After: one refusal, `status=78/CONFIG`, `NRestarts=0`, unit settles in `failed`. Also strengthens the two guard tests. They asserted `pytest.raises(SystemExit, match="1")`, but `match=` is a regex search over `str(exc)`, so it passed for 1, 21, 100 and 111 alike — it read like an exit-code assertion while pinning nothing. They now assert `excinfo.value.code == GATEWAY_FATAL_CONFIG_EXIT_CODE`. The exit code is the contract here: it is the only thing that tells a supervisor the failure is permanent.