fix(gateway): route platform authorization reads through the profile secret scope

[aniruddhaadak80]

What does this PR do?

Fixes a multiplexed-profile isolation break in platform authorization (issue #93522). Under gateway.multiplex_profiles, every secondary profile is constructed inside _profile_runtime_scope and its .env lives in that profile's secret scope — gateway/run.py explicitly does not mutate os.environ with it. Four adapters still read their authorization config via raw os.getenv, producing two failure modes for any non-default profile using them:

1. Fail-closed silent rejection — profile B sets WEIXIN_ALLOWED_USERS=alice (env-only) → raw getenv misses it → intake drops every DM/group message with no error, before the runner-level scoped authz check ever runs.
2. Fail-open cross-profile leak — the default profile's GATEWAY_ALLOW_ALL_USERS=true / allowlists live in the shared process env and leak into B's admission gates.

What changed

Location	Reads routed through the scoped resolver
gateway/platforms/weixin.py	WEIXIN_DM_POLICY, WEIXIN_ALLOWED_USERS, WEIXIN_GROUP_ALLOWED_USERS, WEIXIN_ALLOW_ALL_USERS, GATEWAY_ALLOW_ALL_USERS (via existing _wx_secret)
gateway/platforms/yuanbao.py	new _yb_secret() helper; YUANBAO_DM_POLICY, YUANBAO_DM_ALLOW_FROM, YUANBAO_GROUP_POLICY, YUANBAO_GROUP_ALLOW_FROM; AccessPolicy._open_dm_opted_in
gateway/platforms/signal.py	new _sig_secret() helper; SIGNAL_GROUP_ALLOWED_USERS, SIGNAL_ALLOWED_USERS
plugins/platforms/wecom/adapter.py	existing _get_scoped_secret extended to the authz reads beside the already-scoped credential reads
gateway/run.py::_own_policy_open_startup_violation	GATEWAY_ALLOW_ALL_USERS now via scoped _getenv, matching its sibling dm/group reads

All reads use the canonical fail-closed shape QQ's _resolve_qq_secret already established: scope hit wins; with no scope installed (single-profile deployments), legacy os.environ behavior is preserved exactly. This is the authorization-axis counterpart of #59662/#59739/#86905's credential work, per AGENTS.md §Profiles rule 7 which names {PLATFORM}_ALLOW_ALL_USERS / {PLATFORM}_ALLOWED_USERS / GATEWAY_ALLOW_ALL_USERS explicitly as must-be-scope-aware.

Related Issue

Fixes #93522

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• 🧪 Tests

Changes Made

• Adapter/guard reads listed above; two small module-level helpers (_yb_secret, _sig_secret) mirroring the canonical shape used across ~16 other call sites. No behavior change for single-profile deployments (covered by tests).
• tests/gateway/test_platform_authz_scope.py — 17 regression tests driving the real scope contextvar:
  • each of the four helpers prefers a scope value over os.environ;
  • under multiplex (_MULTIPLEX_ACTIVE=True), a scoped miss returns the default and never falls through to process env (the leak direction), for all four adapters;
  • without a scope (single-profile), os.environ fallback is preserved;
  • WeixinAdapter / wecom _open_dm_opted_in and yuanbao AccessPolicy gates stay closed when only the default profile's GATEWAY_ALLOW_ALL_USERS=true is present, and open on their own scope's opt-in;
  • the yuanbao open-policy startup guard accepts a scope-installed opt-in and rejects when the scope lacks it even though os.environ has it.

How to Test

1. uv run python -m pytest tests/gateway/test_platform_authz_scope.py -q → 17 passed.
2. Neighbors: uv run python -m pytest tests/gateway/test_multiplex_profile_authz.py -q → 5 passed.
3. ruff check gateway/platforms/weixin.py gateway/platforms/yuanbao.py gateway/platforms/signal.py plugins/platforms/wecom/adapter.py gateway/run.py tests/gateway/test_platform_authz_scope.py → clean.
4. Manual (multiplex): configure profiles A+B, put WEIXIN_ALLOWED_USERS=<id> in B's .env only → B now answers allowlisted senders (previously silent); set GATEWAY_ALLOW_ALL_USERS=true in A only → B still denies strangers (previously admitted).

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run targeted test suites locally and they pass
• I've added tests for my changes (required for bug fixes)
• I've tested on my platform: Windows 11

Documentation & Housekeeping

• Docs N/A (matches the documented multiplex contract; comments cite [Bug]: Multiplexed-profile authorization reads bypass the profile secret scope (weixin / yuanbao / signal / wecom) #93522 at each site)
• cli-config.yaml.example N/A (no new config keys)
• CONTRIBUTING/AGENTS N/A
• Cross-platform impact: none (pure env-resolution logic)
• No tool schema change → N/A

Screenshots / Logs

N/A

[alt-glitch]

This was generated by AI during triage.

Related: #88559 repairs the shared authorization-mixin path; this PR covers remaining adapter-local admission reads and the startup check for the same multiplexed-profile isolation family.

[trevorgordon981]

Reviewed from a Hermes audit pass. Correct direction — routing authorization reads through the per-profile scope is exactly what #93522 needs, and routing it through _get_scoped_secret / _getenv is the right canonical shape. One fail-open concern inline, plus a merge-coordination note:

Cross-PR: this substantially overlaps #93545 (same issue #93522, same files) but diverges in approach — #93545 uses the canonical gateway.authz_mixin._platform_gate_env and explicitly leaves weixin/wecom _open_dm_opted_in and Signal unscoped (deferring to the 1,091-commit-stale #88559), whereas this PR fully closes those but invents per-file _sig_secret/_yb_secret helpers instead of routing through a shared one. Merging both will conflict. Worth reconciling with the other author which lands, and confirming #93545's base isn't divergent — the canonical helper it cites isn't present in the current tree.

[trevorgordon981]

This except-fallback fails OPEN to os.environ. For an authorization gate, an UnscopedSecretError resolving to the global/default-profile env is the exact cross-profile leak #93522 describes. It is only safe if every secondary profile is guaranteed to construct inside _profile_runtime_scope; if that invariant ever breaks, a secondary profile silently inherits the default profile's allow-all / allowlists. Safer to fall back only when multiplex is genuinely disabled (an explicit primary-profile path) rather than on a blanket exception swallow. Same pattern applies to _yb_secret (yuanbao.py L1280) and the wecom helper.

[teknium1]

Merged via #93639: your commit was cherry-picked on top of #93545's base (authorship preserved) — your PR was the only one covering signal and the weixin/wecom allow-all gates. Thanks @aniruddhaadak80!