fix: stop a stream on close, count only real users, record where a node is

**Closing the viewer left the node working.** Nothing told it to stop:
the player dropped its handlers, which only made the browser deaf. ffmpeg
kept running and held one of the node's two transcode slots until the
credit timeout expired two minutes later — which is why the next video
answered "server busy". `stream_stop` ends it at once, and the viewer
also drops its queue, ends the MediaSource and revokes the object URL on
the way out, any of which could be holding megabytes of decrypted video.

While there: `file_chunk` replies were matched to their requests by
arrival order, which was true by luck rather than by construction. The
reply now names the file it belongs to and is matched on that and the
chunk index; a chunk nobody is waiting for is dropped instead of being
handed to whatever request happens to be oldest.

**The administration panel counted its own history.** A deleted account
is tombstoned so the connection log stays readable, and every count and
list treated that row as a user — including a group's member count, and
the member list of the group itself. They do not any more.

**Where a node is.** `endpoint_hint` is what a node believes its address
to be, learned from a STUN server and sent to us: useful for reaching it,
and a claim. The announcement that carries it is signed with the node key
over a fresh timestamp, so the address that request *arrives from* is the
address of whoever holds that key — that is now recorded on the node row
and shown in a Nodes tab, next to the hint, with the difference spelled
out. Clients get the same treatment: `webrtc_offer` is logged with the
address the hub saw when a browser starts a peer connection.

Verified against the live deployment: the node's row reads 90.112.206.172
after a restart, and in e2e a stopped stream goes quiet in one message
and the next one starts immediately instead of being refused.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 28 insertions, 0 deletions

diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index 7242dc2..8a55928 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -742,6 +742,11 @@ player consumes it a segment at a time. Segments are 256 KB and the web client
 keeps 24 outstanding, so roughly 6 MB is in flight whatever the film's length. A
 client that sends no credit count gets the old unpaced behaviour.
 
+**Closing the viewer stops the stream.** `stream_stop` tells the node nobody is
+watching, so ffmpeg is killed and its transcode slot released at once. There are
+two slots; before this, leaving a video held one for the two-minute credit
+timeout, which is what made the next video answer "server busy".
+
 **The player drops what has been watched.** A SourceBuffer is not a file: browsers
 cap it and refuse the append that goes past, so anything more than a minute behind
 the playhead is evicted. A segment refused for want of room is retried rather than
@@ -826,6 +831,29 @@ If the keystore password is not stored on the node (`unlock_mode = "secure"`), a
 
 ---
 
+### Where a node is, in the administration panel
+
+The **Nodes** tab lists every registered node with two addresses, and the
+difference between them matters:
+
+- **Seen from** is the address the node's announcement arrived from. That request
+  carries an Ed25519 signature over a fresh timestamp made with the node key, so
+  the address belongs to whoever holds that key. It is IPv4 or IPv6, whichever
+  the node connected over, and it is the one to answer a question with.
+- **Announced hint** is what the node believes its own address to be, discovered
+  through a STUN server and sent to us. It is useful for reaching the node
+  directly and it is a claim, not evidence.
+
+Clients are recorded the same way: `webrtc_offer` in the log is written when a
+browser starts a peer connection, with the address the hub saw it come from.
+Whatever the two peers then discover through STUN is theirs to negotiate and does
+not belong in a log.
+
+Deleted accounts are not counted or listed anywhere in the panel. The tombstone
+row exists so the connection log stays readable (§2) and is not a user.
+
+---
+
 ## 9. Moderation and Legal
 
 ### Who is the legal host