fix(platforms): strip secrets from bridge subprocess env

[necoweb3]

Summary

Strip Hermes secrets from platform bridge subprocess environments.

Raft and WhatsApp both spawn local bridge subprocesses from the gateway process. Those subprocesses previously inherited the full gateway os.environ:

• plugins/platforms/raft/adapter.py used {**os.environ, "RAFT_CHANNEL_TOKEN": ...}.
• plugins/platforms/whatsapp/adapter.py called with_hermes_node_path() with no base env, which copies os.environ.

That leaks unrelated Hermes credentials and gateway-internal secrets into platform bridge child processes, including provider API keys, AUXILIARY_* side-LLM credentials, and GATEWAY_RELAY_* material.

Changes

• Build the Raft bridge env from hermes_subprocess_env(inherit_credentials=False).
• Re-add only the Raft bridge values the child actually needs: RAFT_PROFILE and RAFT_CHANNEL_TOKEN.
• Build the WhatsApp bridge env from the same sanitized helper before adding Hermes-managed Node paths.
• Re-add the WhatsApp bridge values the child actually needs: WHATSAPP_MODE, cache directory paths, and optional reply prefix.
• Add regression coverage proving provider/internal secrets are not passed to either bridge subprocess.

Why

Platform bridges do not need LLM provider credentials or gateway relay credentials. They only need their own narrow bridge configuration. This mirrors the subprocess secret-stripping policy now used by the terminal/codex/docker child-process paths.

Tests

python -m pytest tests/gateway/test_raft_adapter.py -q --timeout-method=thread
17 passed

python -m pytest tests/gateway/test_whatsapp_stale_bridge.py tests/gateway/test_whatsapp_reply_prefix.py -q --timeout-method=thread
19 passed

[teknium1]

Thanks for addressing the verified Raft and WhatsApp bridge leaks. The two proposed bridge substitutions correctly use the existing sanitizer in tools/environments/local.py:471-522 and preserve the bridge-specific values.

Problems

• plugins/platforms/whatsapp/adapter.py:546-552 still launches npm install with with_hermes_node_path() and no base environment. hermes_constants.py:521-523 shows that this copies os.environ, so gateway/provider secrets remain exposed to npm and lifecycle subprocesses.
• A sibling platform sidecar remains unsanitized: plugins/platforms/photon/adapter.py:936-974 copies os.environ and passes it to its Node Popen child.

Suggested changes

• Sanitize the WhatsApp npm-install environment and add an assertion on subprocess.run(..., env=...).
• Apply the same explicit allowlist pattern to the Photon sidecar, restoring only its documented required values and covering it with regression tests.

Automated hermes-sweeper review.

[andrexibiza]

Bound to the child-process credential-inheritance class under #83565 (#83565) — same bug class, different surface. platform bridge subprocess env strip; Wave E — sibling to #38080 on plugins/platforms/whatsapp/adapter.py; adjudicate the pair before merging. The EPIC carries the live class table, dedup adjudication, and the dependency-driven merge order.