fix(gateway): accept named-profile namespace in session-key parsing and sibling lookup

[daerias]

What

Named-profile gateway sessions use namespaced session keys (agent:<profile>:..., see _session_key_namespace() in gateway/session.py). Two core helpers still assume the default-profile literal, so named-profile sessions are misparsed or their sibling lookups silently fail:

Spot	Symptom under a named profile	Fix
_parse_session_key()	key parses to None → routing degrades to the LRU _session_sources fallback	accept any non-empty namespace
_sibling_thread_run_keys()	sibling lookup returns [] → /stop says "no active task to stop" while the sibling keeps running	derive prefix from _session_key_namespace(profile)

Why

• gateway/run.py::_parse_session_key() required parts[1] == "main" — the namespace slot takes no part in any authorization decision, so accepting any non-empty namespace does not weaken any check (same rationale as in [Bug]: qqbot approval buttons rejected as unauthorized in named-profile sessions (session-key namespace vs "main") #98292).
• gateway/run_busy.py::_sibling_thread_run_keys() hardcoded the prefix as agent:main instead of using the namespace build_session_key() itself produces.

Changes

• _parse_session_key(): accept any non-empty namespace slot instead of asserting parts[1] == "main". Malformed keys (agent::..., wrong prefix, too few parts) still return None.
• _sibling_thread_run_keys(): build the prefix via _session_key_namespace(getattr(source, "profile", None)) — byte-identical agent:main for default/unset profiles.

No behavior change for the default main case.

Tests

Reproduce: with a named profile serving any chat platform, trigger a background-process notification or /stop a sibling thread run — before: silent fallback / "no active task to stop"; after: correct routing and sibling match.

• 4 new regression tests: named-profile parsing (plain + dm/thread-with-extra), malformed-key rejection, named-profile sibling matching.
• pytest tests/gateway/test_background_process_notifications.py tests/gateway/test_stop_thread_sibling.py -q → 30 passed.
• Full gateway suite on this host: 7889 passed, 14 failed. Of those, the same 7 environment-dependent failures reproduce identically on clean main (verified in isolation on main@b2aa855b62); the other 7 pass in isolation on this branch — order-dependent suite flakiness, not caused by this change.

Platforms

Tested on macOS (arm64). The changed paths are platform-independent; Linux-gated gateway paths were not exercised live on this host.

Related

• [Bug]: qqbot approval buttons rejected as unauthorized in named-profile sessions (session-key namespace vs "main") #98292 (open) — same bug class (qqbot approval buttons); this PR complements fix(qqbot): authorize approval buttons for named-profile session keys #98294, which fixes only the QQBot adapter. The two PRs are orthogonal and can merge independently.
• agent:main hardcoded in _parse_session_key and run_busy breaks named-profile session keys (multiplexing) #105931 — earlier report of these two spots; closed as duplicate of [Bug]: qqbot approval buttons rejected as unauthorized in named-profile sessions (session-key namespace vs "main") #98292.

Not in scope

_build_process_event_source() in run_notifications.py still rewrites named-profile keys to agent:main before parsing — redundant and harmless after this fix; candidate for a separate cleanup PR.

Checklist

• Conventional commit (fix(gateway): ...)
• Regression tests for both fixed paths; targeted suites green
• No unrelated changes; default-profile (agent:main) behavior byte-identical

[alt-glitch]

This was generated by AI during triage.

Duplicate of #105942, which landed first with the same _parse_session_key / _sibling_thread_run_keys namespace fix (and also patches gateway/run_notifications.py). #105943 is a third copy. Thanks for the issue report (#105931); if this PR has a delta the others lack, please note it here.

[daerias]

Thanks for the triage. Checked #105942's diff — it covers both spots plus the run_notifications.py cleanup, so no reason to keep this one open. Closing this in favor of it. Thanks @kokhlo for the complete fix!