fix: say "Connected" even when there is no terminal to spin on

[leggetter]

Closes #376.

What was wrong

hookdeck listen connected, forwarded events, and never said it was ready.

SimpleRenderer.OnConnected kept its whole body — the readiness line and the active-filters notice — behind if r.spinner != nil. ansi.StartNewSpinner returns nil when the writer is not a TTY or colors are disabled, so Connected. Waiting for events... was dropped whenever output was piped or --color off was passed. README documents that line for both compact and quiet, so callers waiting on it were right to wait; they just had no way to stop waiting.

The writer is log.StandardLogger().Out — stderr. Nothing calls SetOutput, so whether a line reached stdout was decided by whether stderr was a terminal. A wrapper that gave stdout a PTY and piped stderr lost the line too. #333 downgrades --output interactive to compact without a terminal, which steers non-interactive callers straight onto this renderer.

Reported from the field as a websocket failure. The websocket was healthy.

What changed

• ansi.CanSpin(w) — makes "can a spinner be drawn here?" a question you can ask, so the next caller doesn't have to read nil as "nothing to say". StartNewSpinner now uses it, same behaviour.
• SimpleRenderer.showStatus / stopStatus — spinner on a terminal exactly as before; a plain stdout line otherwise.
• OnConnected prints unconditionally.
• OnDisconnected had the same shape (message to stderr, bare newline to stdout) and is fixed the same way.

Net effect: readiness, reconnection and events all land on stdout, so one stream carries the whole state machine.

Verification

New tests in renderer_simple_test.go exercise the no-spinner path directly — readiness in compact and quiet, readiness under --color off, the drop notice reaching stdout, silence when the first attempt fails, and no duplicate notice across a reconnect. All five assertions fail against the unfixed renderer:

Error: "" does not contain "Connected. Waiting for events..."
Error: "\n" does not contain "Connection lost, reconnecting..."

End-to-end, a binary built from the v2.5.0 tag was run against a local stand-in for api.hookdeck.com / ws.hookdeck.com with a real PTY, then rebuilt from this branch:

Case	v2.5.0	This branch
--color off, PTY	no readiness line (websocket up, 101 + pings flowing)	Connected. Waiting for events...
stdout+stderr piped, no --color	no readiness line	Connected. Waiting for events..., stderr now empty
TTY with colors	spinner then readiness	unchanged; line printed exactly once

go test ./... green.

Release

Targets main, shipping in v2.6.0 (a v2.5.1 patch was considered and dropped). KNOWN_ISSUES.md names v2.6.0 as the version to upgrade to. release/v3.0.0 carries the identical bug and already contains all of main, so it should take this via a merge of main rather than a cherry-pick.

Also here: saying why a connection failed

Added after the patch release was dropped in favour of v2.6.0 - "too broad for a patch" was the only reason it was held back, and that reasoning expired with the patch.

listen gave up with Could not connect. Terminating after 10 failed attempts to establish a connection. and no reason. The dial error existed in connect() but was logged at debug, so at the default log level the user learned the CLI had stopped trying and nothing about whether it was DNS, a refused connection, a proxy, or a rejected session.

That is the other half of the same report. The readiness line says when the tunnel came up; this says why when it did not. A caller who saw neither could not tell a healthy tunnel from a broken one, which is how a working connection got filed as a failure in the first place.

Could not connect. Terminating after 10 failed attempts to establish a
connection. Last error: dial tcp [::1]:39999: connect: connection refused

Verified by rebuilding and re-running the dead-endpoint reproduction that produced the reasonless message. TestLastConnectErr covers the client side.