Per-session teardown: drop delegated MCP token + connection at session end (#317 follow-up)

[initializ-mk]

Carved out of the #317 epic. Per-user tokens (#327) and connections (#329) resolve lazily and are keyed by `subject`; the auth-required gate (#330 / PR #331) parks and resumes. What's missing is the teardown end of the lifecycle — dropping a user's delegated token + connection when their session ends.

Problem

Today the delegated per-user token + connection are torn down only:

• at server stop — `subjectConnPool.Close()` tears down the whole pool (`server.go:441`), and
• on TTL expiry — `memSubjectTokenStore` sweeps expired tokens opportunistically.

There is no per-session-end teardown. The #317 acceptance calls for: "session end drops token + connection; new session re-consents." Without it, a subject's token + live MCP connection persist past the session that established them — up to the token TTL / process lifetime — which is both a footprint and an isolation concern (a new session should re-consent, not silently reuse the prior session's grant).

Scope

• Thread a session id onto the invocation (work-breakdown item 1 notes this is needed) and make the delegated token cache + connection pool aware of it, or maintain a subject→session binding.
• On session end, drop that subject/session's token (`SubjectTokenStore.Evict`) and connection (`subjectConnPool.Evict` / `Close` for that entry) — the primitives already exist; they need a lifecycle trigger.
• A new session for the same subject with no live grant re-enters the auth-required gate (re-consents) rather than reusing a stale connection.

Decisions to make

• Isolation unit: feat(mcp): per-user connection lifecycle — pool + routing seam + materialized type=user servers (#317 increments 1–3) #329 pools by `subject`; the epic says "per subject/session." Decide whether a single user's concurrent sessions share one connection (current) or get separate ones. Sharing is cheaper but couples session lifetimes; separate honors "new session re-consents" strictly. (Note the Epic: runtime per-user, ephemeral per-session MCP OAuth (interactive login via Slack / A2A UI) #317 risk: N users ⇒ N live connections — a per-session split multiplies this, so a cap / eviction policy should land with this.)
• Session-end signal: what marks "session end" for Slack vs A2A/UI — last task in a conversation, an explicit close, or an idle timeout.

Already in place (build on these)

• `subjectConnPool` with lazy establish + `Evict` + `Close` — feat(mcp): per-user connection lifecycle — pool + routing seam + materialized type=user servers (#317 increments 1–3) #329.
• `SubjectTokenStore` interface with `Evict` + TTL sweep — PR feat(mcp): auth-required gate for delegated MCP consent (#330) #331 inc 5.
• The gate that re-parks a grantless call — Auth-required gate: DEFER park/resume for delegated MCP consent (#317 follow-up) #330 / PR feat(mcp): auth-required gate for delegated MCP consent (#330) #331.

Acceptance

• Ending a session evicts that subject/session's delegated token and tears down its MCP connection.
• A new session for the same subject with no live grant re-consents (re-enters the gate) rather than reusing the prior connection.
• A connection cap / eviction policy bounds N-concurrent-user connection growth.
• No delegated token persists past its session (beyond the TTL backstop).

Out of scope

• Standalone consent delivery — separate Epic: runtime per-user, ephemeral per-session MCP OAuth (interactive login via Slack / A2A UI) #317 follow-up.
• Managed token custody — platform-side.

Related

Epic #317 · tokens #327 · connections #329 · gate #330 (PR #331) · AARM R10 #319 · authority `design-tool-registry.md` §18.