Scope TUI session list and auto-resume to the active profile DB

[necoweb3]

Summary

This makes the TUI session picker and auto-resume path read from the same profile-owned state that session.resume already uses. Today, a profile-resume can hydrate the correct profile workspace and runtime session, but session.list and session.most_recent still read the launch profile DB through _get_db(), so the picker can show the wrong recent sessions after switching profiles.

Why

Profile resume is supposed to restore the active profile's own workspace and persisted session state. If the resume path comes from profile_home but the history/most-recent paths still come from the launch DB, the UI can point the user at a different session list than the one actually owning the resumed workspace.

Changes

• Scope session.list to the active profile when params.profile is present.
• Scope session.most_recent to the active profile when params.profile is present.
• Preserve the current launch-profile behavior when no profile override is provided.
• Add regression coverage for profile-resume + list/most-recent divergence.

Tests

python -m pytest tests/test_tui_gateway_server.py -k "session_list or session_most_recent or session_resume_profile" -q --timeout-method=thread

[alt-glitch]

Duplicate of #47294 — the api_server.py _conversation_store_key() change here is byte-for-byte identical to #47294 (same author, opened ~18 min earlier), which is the focused canonical for scoping Responses-API conversation names by session key. This PR's title ("Scope TUI session list and auto-resume to the active profile DB") does not match its diff — there are no tui_gateway/ changes; the diff is the conversation-key-scope fix plus a webhook delivery-retry change, and it bundles three unrelated *-pr.md planning docs (stacked-branch contamination). Recommend reviewing #47294 instead.