The commit before this one names the connection failure and passes
`"listener", l.id` beside the reason. The logger it writes through already
carries that key — `AddListener` builds it with
`s.Log.With(slog.String("listener", l.ID()))` and `Init` is the only place a
listener is given one — so every line reads:

    level=WARN msg="failed to establish connection" listener=t1 error=ending listener=t1

Nothing is wrong or missing in it. It is said twice, which an operator reads
past as ordinary and a pipeline keyed on the field records twice.

Six sites, not the four this branch added: `websocket.go:121` and
`http_sysinfo.go:94` do the same in `"failed to serve."` and are on main
today. The id stays on every line — it is the logger's, and the call sites
stop repeating it.

Visible only on a terminal. The `With` and the call sites are in different
files and each is right on its own, which is how the same line came to be
written six times.

So a test that reads one, and a test that asks the question of the package.
TestListenerLogLineNamesTheListenerOnce serves through a logger built the
way AddListener builds it and requires `listener=` exactly once; against the
previous commit it fails with the line above quoted back. It waits for the
line rather than for Serve to return, because the Warn is written from the
per-connection goroutine that nothing joins — waiting on Serve reads an
empty buffer often enough to matter, and then the assertion turns on the
scheduler rather than on the code.

TestNoListenerLogCallPassesTheListenerKey walks the syntax tree of every
non-test file in the package and fails on the literal key at any log call,
so that a seventh site cannot be added quietly. The tree rather than the
text, so a call gofmt has wrapped is not invisible; and it counts the files
it read and fails on an implausible number, so a walk that finds nothing
because it looked nowhere cannot pass as a clean one.

Signed-off-by: Italo Nesi <inesi@confluent.io>

The message this branch chose is wrong for most of what reaches it.
`Serve` calls `establish(l.id, conn)` once per connection and that call runs
the *whole* session — it returns when the session ends, at any point. So a
publish refused an hour into a healthy connection is logged as:

    msg="failed to establish connection" error="packet too large"

which reads as a client that never got in. An operator chasing why a device
cannot connect finds these and is looking at the wrong thing entirely.

"connection ended with an error" is true wherever the error came from — a
handshake refused, a malformed packet, a keepalive expiry — and that is the
most the listener can honestly say, because the listener cannot see which
of them happened. Only the error beside it can, and it is already there.

Found by an oversized publish on an established connection, which is the
case that makes the difference visible: everything else this line reports
does happen at connect time, which is presumably how the wording was chosen.

Signed-off-by: Italo Nesi <inesi@confluent.io>