fix(core): disconnect the live session of a user who was just removed

[shenaba]

Closes #175.

The hole

Protocols that authenticate once per session keep serving a client after its
user is gone from the inbound. Swapping the user table only decides who may
start a new session; ConnTracker closes the routed connections but not the
session carrying them, so the client opens another stream on the one it already
has and is served. Every multiplex session has the same shape — one
authenticated carrier connection serves every stream opened after it.

Measured on the test server against main, a client DepleteJob had just
disabled for running out of quota was served 11 out of 11 retries on anytls,
hysteria2 and vless+mux alike.

Two kinds of session

anytls and the sing-mux carrier arrive as a net.Conn that lives exactly as
long as the session does. core/usersession tracks those by source address and
closes them outright — the key is one TCP connection's address, it cannot move,
and Untrack runs when the session ends. That is the whole story for anytls,
vless, vmess and trojan, and it disturbs nobody else on the inbound.

The QUIC protocols give this layer no handle on the session, and no usable
name for one either:

• sing-quic keeps its session list unexported, and the ctx it hands the
  handler per stream is the Service's own (serverSession{ctx: s.ctx}),
  shared by every session on the listener;
• all three services set quic-go's DisablePathManager, which rewrites a
  connection's remote address the moment a decryptable packet arrives from a new
  one, with no path validation — one NAT rebind and the address is different;
• that address is an ephemeral UDP port, recycled to somebody else once the
  session ends, and nothing tells this layer that it has been;
• and there is no moment at which a QUIC session can be declared gone.
  quic-go keeps one alive with a 10s PING whether or not a single byte is
  routed, so an idle session and a dead one are indistinguishable from here.

Two earlier revisions of this PR tried to do better and could not. Muting the
source address is defeated by the second and third points. Ageing a per-session
entry out after ten idle minutes — which is what the first review round of this
PR produced — is defeated by the fourth: a client idle past the window was
dropped from the registry, no restart was asked for, and its still-authenticated
session went on being served. That is #175 verbatim. Both versions looked fine
because a probe that reconnects every second is never idle and never moves.

What this does

For QUIC the registry does not track sessions at all. It records something
weaker and completely reliable: which users have been seen on this inbound.
That set is keyed by user rather than by address, so a client whose address
moves is still one entry; and it is bounded by the client count rather than the
session count, which is what lets it carry no expiry at all. A set with no
expiry is the only kind that cannot be wrong about a session it cannot see.

CloseUsers cuts every session it holds a transport for and reports the rest as
Unclosable. The QUIC inbounds turn that into ErrRestartRequired, and
InboundService.UpdateInboundsUsers rebuilds the inbound — the same
RemoveInbound/AddInbound path protocols with no in-place update already
take. That destroys every QUIC session on the listener, the removed user's
included.

Nothing in core/usersession refuses a connection any more, in any mode.

What it costs

On a QUIC inbound, disabling a user who has been connected disconnects
everyone on that inbound once. They reconnect on their own.

Being wrong here is one-sided on purpose: a user who connected and then left for
good is still in the seen set, so removing them costs one restart that bought
nothing. The other direction — deciding a session is gone when it is not — is
issue #175, so the cost is paid on that side.

It is not paid otherwise: adding a user, rotating a UUID or password, or
removing a user who never connected all still update in place. DepleteClients
disables every expired client in one transaction and calls
UpdateInboundsUsers once with the union of their inbounds, so a deplete round
costs at most one restart per inbound, not one per client.

One line per copy

Unchanged, and scripts/check-protocol-copies.sh still reports 8/8 ok against
sing-box v1.14.1 with the same expect_diff counts: everything here lives in
users.go (exempt) or in the header comment above the package clause (which
the script strips). Six copies carry the single line

inbound.router = withUserSessions(inbound.router)

and anytls costs three, because it holds its session in NewConnection, which
the router never sees.

Verification

The hole is measured; this implementation is not yet. The 11/11 figure above
was taken against main and stands as evidence that the bug is real. What has
been verified for the code in this PR is everything below the network:

• the full PR gate — check-protocol-copies.sh (8/8), go vet, go build and
  go test ./... with the CI tag set, all green;
• core/usersession clean under -race, including a stress run driving every
  exported method from eight goroutines at once, which also asserts that the
  seen set grows per user and not per address;
• mutation testing, 16/16. Every behaviour this package claims was backed
  out one at a time and the matching test confirmed to go red — including
  "expire an idle user out of the seen set", which is the defect described
  above, and "key the seen set by address instead of user".

Mutation testing is also what makes the review trail below worth trusting
rather than just worth reading: the ten-minute-idle defect was found by a code
review that ran after a 12/12 mutation score, because the suite at that point
had the wrong behaviour written into it as an assertion
(TestSweptSourceIsNotReportedUnclosable). That test is gone, replaced by
TestIdleUserIsNeverForgotten.

Not covered by anything automatic: the one line in each QUIC users.go that
turns Unclosable into ErrRestartRequired. Constructing an *Inbound needs
the whole of NewInbound (TLS config, listener), which is too much to stand up
in a unit test. Result.RestartRequired itself is table-tested, and the seven
call sites were checked by hand — the three QUIC protocols call it, the other
four deliberately do not and say why.

Still to do before merge: a run on the test server — deplete a connected
client on a hysteria2 inbound and confirm both halves, that it is actually cut
off and that the inbound comes back. Worth doing with an idle client too,
since that is the case both earlier revisions got wrong.

Known edges

• shadowsocks is not covered. It has the same multiplex hole but still runs
  sing-box's own inbound; forking it belongs with the live-traffic work.
• KickUserSessions exists and is tested, but has no caller until the
  panel-side disconnect lands. On a QUIC inbound it can only report
  Unclosable — whether disconnecting one user is worth restarting the inbound
  everyone else is on is a decision for that caller, not this layer.
• RemoveInbound then a failing AddInbound leaves the inbound gone from the
  core while the transaction rolls back, and checkCoreJob will not notice
  because the core itself is still up. That is pre-existing behaviour for every
  protocol without an in-place update, but QUIC deplete now takes this path
  routinely, so the exposure is larger than it was. Not addressed here.
• The real fix for QUIC is upstream: Close sessions of removed users on UpdateUsers SagerNet/sing-quic#19 and
  fix: close sessions of removed users on UpdateUsers anytls/sing-anytls#4 are still open. A per-session handle would turn the
  restart back into a targeted close.