Log session_id on engine session close

[leifj]

Summary

• Live triage of the Geneva 2026 test event (see sirosid-dev/gdc) reported apparent continuous engine-session flapping - sessions established then immediately closed - which looked like a server-side session-map bug.
• Reading internal/engine/session.go closely: registerSession/unregisterSession's map handling is correct (the current == session pointer-equality guard in unregisterSession already prevents an evicted connection's cleanup from deleting the replacement session's entry). The real defect is purely in logging: session.logger's bound "session" field is set to the user's short ID (not the session's own) whenever authenticated, specifically so log lines from the same user's repeated reconnects grep together - but this means two rapid reconnects for one user produce two "Session closed" lines with no way to tell which session actually closed, unlike "Session established" which already logs an explicit session_id.
• This PR adds the same explicit session_id field to the "Session closed" log line, so a real reconnect storm (driven by a duplicate-client bug on the SDK side, tracked separately) can actually be distinguished from a server-side eviction bug in logs going forward.

Test plan

• GOWORK=off go build ./internal/engine/...
• GOWORK=off go test ./internal/engine/... - passing
• Pre-commit hooks (gofmt, golangci-lint) passing

🤖 Generated with Claude Code

https://claude.ai/code/session_014CUkUYCxTRRRrvVWSGS5dj

[Copilot]

Pull request overview

This PR improves observability for WebSocket engine sessions by including an explicit session_id field in the "Session closed" log line, matching the existing "Session established" logging and making rapid reconnect/close sequences distinguishable in production logs.

Changes:

• Add zap.String("session_id", session.ID) to the "Session closed" log entry in Manager.unregisterSession.
• Add an explanatory comment clarifying why session.logger’s bound "session" field can’t be relied on to uniquely identify a specific session instance.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/engine/session.go	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[leifj]

This needs a config gate and should only be logged in debug-mode to avoid leaking privacy sensitive data