fix(adk): session query/manage APIs accept an explicit user_id

[shoom1]

Review finding 5, countered

The finding is technically correct: process() accepts arbitrary user_id (and job-resume threads record.user_id), while session_exists / list_sessions / delete_session / recent_messages hard-coded settings.default_user — sessions created for a non-default user were unreachable through the framework API.

But the proposed fix (a required typed (app_name, user_id, session_id) identity across all processing and session methods) is over-engineering here: ADK's session service already namespaces by exactly that tuple internally, and the shipped CLI is single-user — message_processor passes settings.default_user everywhere, so no current caller can hit the mismatch. The LangGraph thread_id half of the finding targets a backend slated for retirement and is deliberately not addressed.

Change

Keyword-only user_id: str | None = None (defaulting to settings.default_user) on the four ADK session methods. Existing callers are untouched; multi-user library consumers can now manage the sessions they create.

Tests

TDD: seeded sessions under two users against a real sqlite DatabaseSessionService; asserts default scope stays unchanged, explicit scope reaches the other user's session through all four APIs, and cross-user operations don't leak. Full offline suite: 1982 passed.

https://claude.ai/code/session_01SwkKXQpy3JLEqrPkQA8QRv

[shoom1]

Superseded by #110.

The framework review series includes this work in feat(workflow)!: SessionRef and user-scoped session APIs (68f8724), which generalizes it: every session hook takes an optional user_id (not just the ADK query/manage APIs), identity becomes the SessionRef(app_name, user_id, session_id) triple, the active turn is a ContextVar, and a backend with no durable store raises NotImplementedError rather than answering False/[].

Closing unmerged — the content is a strict subset of #110, not a dropped change.