the displaced stream was closed without a word

the displaced stream was closed without a word

When a new read stream arrives for a session that already has one, the daemon
replaces the old with the new: that is the intended behaviour, it is what
lets you carry on from where you were after a browser restart.

The displaced client, though, was told nothing: its socket was simply closed.
It reopened it, displacing the new one in turn, which reopened in turn: two
windows open on the same session bounced each other forever, each with a red
indicator and no explanation.

Now the replaced stream is dismissed: it stops the streaming and shows a
notice. It is not sent back to the login, because when the two windows share
the same session the entry page would let it straight back in, starting the
bouncing again.

The message travels over the transport of the OLD connection, which may
differ from the one of the new, and is followed by an orderly close
(stream_bye in user.phh). In the normal case - the same client reopening
after having given the connection up for lost - it ends up on a socket nobody
reads any more and does no harm.

Checked with two streams on the same session, in both combinations: the first
receives xstm.stop() and the notice, as text over xhr and framed (0x81) over
websocket, and is not sent back to the login. A complete game confirms the
normal path is intact.

NOTE: the case of a login by a user already present was handled before, by
the "ghost" mechanism of add_user(): the new access inherits the old user,
seat at the table included, and the displaced session is recorded in
ghost_sess with reason ANOT, which index.php turns into "La tua sessione e'
stata assegnata ad un altro browser". What was missing is precisely the piece
added here: if the displaced client was reading a stream, it never reached
index.php and never saw that message.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014M1jiEq9cHdE5SE5j6vFuE