When using daphne, if some process is already listening on our preferred port, `runserver` does not exit with a failure code.

if some server process is already listening on our preferred port, runserver does not exit with a failure code, but instead keeps running (even though the underlying daphne process has logged an error complaining about EADDRINUSE).

To reproduce the problem:

- clone [the "repro-daphne-trouble" repository](https://github.com/offby1/repro-daphne-trouble.git), and cd to its top-level directory (i.e., the folder that holds `README.md`)
- install [uv](https://docs.astral.sh/uv/#installation)
- run `uv run python manage.py runserver`; note that it's working fine
- in another window, again run `uv run python manage.py runserver`. This time, you'll see `Listen failure: Couldn't listen on 127.0.0.1:8000: [Errno 48] Address already in use.`, but the process doesn't exit. The "Listen failure" message is expected, but the bug is that the process should exit with a nonzero status.

Notes:

- If, instead of `uv run python manage.py runserver`, you run `uv run daphne repro.asgi:application` (which is roughly equivalent), it works fine: the first process starts, and the second one *both* reports `2026-02-08 21:32:24,523 CRITICAL Listen failure: Couldn't listen on 127.0.0.1:8000: [Errno 48] Address already in use.` *and* exits with status 1.
- If you check out the [latest commit before adding daphne](https://github.com/offby1/repro-daphne-trouble/commit/3af53e41256ed9211b06689ca33dd24b44d9d0fb) and try running two copies of "runserver", they work fine (i.e., the second process exits with a status of 1). So the problem is in some interaction with "runserver" and "daphne".
- There was a similar-seeming bug in daphne (#552) that might have caused a similar problem, but it's irrelevant since it's been fixed for at least a year.