GeezerVison

Closes #27006.

Summary

Today the connection log has no user attribution for SSH / IDE sessions. The
agent reports ssh / vscode / jetbrains / reconnecting_pty rows, but by
the time the connection reaches the agent the Coder user identity is gone — see
the comment in coderd/agentapi/connectionlog.go:

// It's not possible to tell which user connected. Once we have the // capability, this may be reported by the agent.

As a result connection_logs.user_id is always NULL for those rows, and there
is no way to answer "which Coder user opened an SSH session into workspace X"
from the connection log alone. For enterprise audit use-cases (cross-user
workspace access, long-lived-token misuse) that's a significant gap.

Every such session is carried over a tailnet tunnel that the client opens via
GET /api/v2/workspaceagents/{id}/coordinate. That request is made with the
user's API key, so coderd does know who is connecting at that moment.

This PR adds a new connection_type value tailnet and writes one connection
log row from workspaceAgentClientCoordinate each time a client successfully
upgrades the coordinate WebSocket. The row carries:

• user_id — from httpmw.APIKeyOptional(r)
• ip / user_agent — from the HTTP request (real client IP once
  CODER_PROXY_TRUSTED_* is configured)
• workspace_id / agent_name — the tunnel target

The event is treated like the other coderd-originated connection types
(workspace_app, port_forwarding): it's a point-in-time authorization event
with no disconnect_time, so it's excluded from the status: filter and
rendered via WebInfo (which already surfaces the connecting user in the
dashboard).

Why not fill user_id on the existing SSH rows?

Those rows are emitted by the agent over ReportConnection, which doesn't have
access to the Coder user or API key (the comment above is still accurate).
Plumbing identity down to the agent would be a protocol change; this approach
gets the same attribution without touching the agent API.

What about /api/v2/tailnet (Coder Desktop)?

tailnetRPCConn is user-scoped rather than workspace-scoped, so it doesn't
have a single target workspace to log against. It already reports
UserTailnetConnection telemetry. I've left it out of this PR to keep the
change small; happy to follow up if there's interest in logging it too.

Notes

• Volume: this fires once per client tunnel (not per SSH exec), so it's the
  same order of magnitude as coordinator handshakes — typically far below the
  workspace-app rate.
• Requests that arrive via workspace-proxy auth (no API key on the route) are
  skipped.
• api_key_id isn't recorded because connection_logs has no column for it;
  user_id + user_agent + ip is what the existing web types store too.
  I'd like to add an api_key_id column in a follow-up (or here, if preferred)
  so these rows — and potentially workspace_app / port_forwarding rows —
  can also record which key was used; it's available at both write sites.
• This fires for every DialAgent caller (coder ssh, coder port-forward,
  the VS Code extension, coder ping, coder speedtest, etc.), so a tailnet
  row means "user opened a tunnel to this agent", not "user ran SSH". There is
  currently no debounce on reconnect; if volume turns out to be a concern the
  same workspace_app_audit_sessions pattern could be applied here.
• Happy to rename tailnet → tunnel (or similar) if that reads better.