Don't let server replay override a response set by an earlier addon - #8563

Description

Fixes #6113.

ServerPlayback.request() ran even when a script or an earlier addon had already answered the flow. With server_replay_extra=kill, the client was disconnected while the flow still showed the script's response, which is the case from the issue. With a status code, the response was silently replaced. If a recorded flow matched, its response replaced the script's too.

It now returns early when the flow already has a response or an error, or isn't live. That is the same guard MapLocal and MapRemote use.

The same applies to default addons that answer earlier: ProxyAuth's 407, BlockList and Onboarding. For example, with a matching recording on main, a client that fails proxy auth gets the recorded response instead of the 407.

One behaviour change to note: when a flow is already answered, a matching recording is no longer used up. Later identical requests in non-reuse mode therefore get the recordings one step earlier than before. If you would rather keep the guard to the server_replay_extra branches, as in your comment on the issue, I can narrow it.

New tests in test_serverplayback.py:

• a response set before server replay is kept with kill, 204 and 404;
• it is also kept when a recording matches, and the recording stays available for the next request;
• a killed flow is left alone (on main, kill raises "Flow is not killable").

All of them fail on main. The full test suite passes, and ruff and mypy are clean. This should rebase cleanly with #8365, since the guard runs before the branch that PR moves.

Checklist

• I have updated tests where applicable.
• I have added an entry to the CHANGELOG.