feat: Session Bus — real-time cross-session heartbeat registry

[creandoaldia]

What

Adds a Session Bus layer for real-time cross-session awareness. Sessions send periodic heartbeats with task descriptions, and Engram tracks active sessions with a 2-minute staleness window.

How it works

Each coding session sends a heartbeat on every tool call (throttled to 30s):
\
POST /sessions/{id}/heartbeat → returns list of other active sessions
\\

Other sessions can query the bus:
\
GET /sessions/active?project=X → all sessions with recent heartbeats
\\

Stale sessions (no heartbeat in 2 min) are auto-cleaned on every read.

Changes

Store (store.go)

• \session_heartbeats\ table (session_id, project, current_task, status_blob, last_seen)
• \ActiveSession\ struct
• 5 methods: \UpsertHeartbeat, \UpdateSessionStatus, \CleanStaleHeartbeats, \ActiveSessions\

MCP (mcp.go) — 3 new tools (agent profile, 22 total)

• \mem_session_heartbeat\ — send heartbeat + receive active sessions list
• \mem_session_status\ — store detailed JSON status blob
• \mem_active_sessions\ — read-only list of active sessions

HTTP (server.go) — 3 new endpoints

• \POST /sessions/{id}/heartbeat\
• \POST /sessions/{id}/status\
• \GET /sessions/active?project=X\

Dependencies

Zero. No new imports, no new services, no Redis, no WebSocket. Pure SQLite + existing REST API.

Companion PRs

• OpenCode plugin heartbeat hooks: https://github.com/creandoaldia/web-ai-lab
• Model routing + env cleanup: https://github.com/creandoaldia/premium-static-landing-001

[Alan-TheGentleman]

Closing this because it introduces a new Session Bus architecture without an approved issue or design discussion. This changes Engram's runtime coordination model through store tables, MCP tools, and HTTP endpoints, so it needs a real proposal first. Open an issue describing the problem, the intended contract, and the tradeoffs, then we can discuss whether this belongs in Engram before any PR.