fix(gateway): match the profile-namespaced session key in the clarify bypass lookup

[ygd58]

Fixes #82975.

Root cause

The adapter-level clarify reply bypass in gateway/platforms/base.py's handle_message() built its session_key via build_session_key(...) without a profile= argument, defaulting to the legacy agent:main namespace. The runner registers pending clarifies under SessionStore._generate_session_key()'s key, which DOES include profile=self._resolve_profile_for_key(source). Under a named-profile multiplex these diverge, so the bypass lookup misses -- the user's answer to a pending clarify() gets routed to the adapter's busy-session queue instead of resolving it, and the turn hangs until the 3600s timeout. Matches the reported Telegram symptom exactly (no inbound message: log line, no clarify-intercept log line).

Verified the divergence directly by reading both key-construction sites. _resolve_profile_for_key() returns None when multiplex_profiles is off (default) -- byte-identical to the prior implicit profile=None, so this only changes behavior for multiplexed deployments, matching the issue's exact reported scope.

Fix

Uses the same self._session_store._resolve_profile_for_key() the runner's key generator calls, guarded with getattr() + a None fallback since _session_store is set via a setter and can be unset for some adapters.

Verification

Added a regression test alongside the existing bypass coverage. Verified as a genuine regression by reverting the fix and confirming the new test fails with the exact reported symptom.

21/21 pass across the five directly related clarify test files; 16/16 across broader multiplex/clarify-progress tests (no regression).

[fmercurio]

Thanks — I reviewed this against an independent named-profile Telegram reproduction, and the profile-qualified active-session lookup is the right fix for the clarify bypass in #82975.

One adjacent path remains: Telegram _photo_batch_key() currently builds its burst/album key without the routed profile, so named-profile photos can still be buffered in the legacy namespace before handle_message() runs. There is also a separate ordering case where an uncaptioned image reaches the busy queue just before an open-ended clarify is registered.

I will prepare a small, separately tested follow-up against current main, linked to #82975 and explicitly excluding this PR's base-key change so it is not a competing implementation. The follow-up will use generic fixtures and exact-event identity checks to avoid consuming a later replacement message or duplicating a prompt. If you prefer a different split, please say so here; I do not have push access to this branch.