docs(agent-server): say what --token does not buy

[ericleepi314]

#924 made --token mandatory off loopback and explained why it is required. It
never said what the token stops short of, which leaves the paragraph reading as
"bind wide, pass a token, you're fine."

Both listeners are plaintext. The bearer token rides an Authorization
header over http://, and POST /sessions replies with a ws:// URL carrying
the per-session token as a query parameter:

ws_url = f'ws://{host}:{ws_port}/ws/{info.id}?token={token}'

There is no TLS anywhere in that server. So --token answers who may
connect, not who may watch — anyone positioned to read the traffic, rather
than merely to reach the port, can lift either token and create sessions
afterwards.

That makes a remote bind defensible on a trusted network or behind a TLS
terminator, and not defensible on its own over the internet. The docs now say
so.

Deliberately unchanged: the refusal message and the --token help text.
Both were already accurate — they state what is wrong without a token and
claim nothing about what having one achieves. Only the prose someone plans a
deployment from needed the caveat.

Raised in review of #924, and verified against the code rather than taken on
report — grep for ssl/TLS in src/server/server.py returns nothing, and the
ws_url line is quoted above. This is the same failure shape as the #920
correction: a true fact (--token gates POST /sessions) carrying an
inference I had not checked (that it therefore makes the bind safe).

Docs only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WAB22BuCSRhjbpR3a8kc5v

[github-actions]

Test Results

     5 files   1 009 suites   30m 10s ⏱️
15 749 tests 15 723 ✅ 22 💤 4 ❌
31 604 runs  31 534 ✅ 66 💤 4 ❌

For more details on these failures, see this check.

Results for commit fd2f5ec.