fix(relay): carry routed profile through the passthrough-plane forward

The relay text lane stamps `SessionSource.profile` from the wire frame
(#60586), but `PassthroughForward` had no profile field, so a relayed
Discord slash-command/button/modal always landed in the default profile's
agent:main namespace even when the connector resolved a specific profile.

Add an optional `profile` to `PassthroughForward` (read off the wire in
`_passthrough_from_wire`) and stamp it on the interaction's SessionSource.
Absent on the wire → None → legacy routing, byte-identical for
single-profile gateways. Contract doc updated.

Salvaged from #61012 (pierrenode); two context conflicts resolved
(delivered_via_upstream_relay / _platform_by_chat landed on main).

docs/relay-connector-contract.md

@@ -119,8 +119,13 @@ Both absent ⇒ byte-identical to today. A connector that never sends them, or a
 
 `PassthroughForward` is the wire form of a forwarded passthrough-plane request
 (Class-2/3 webhooks — Discord interactions, Twilio): `{platform, botId, method,
-path, headers: [[k,v],…], bodyB64}`. The body is base64-encoded so arbitrary
-bytes survive the newline-delimited-JSON transport; the gateway base64-decodes
+path, headers: [[k,v],…], bodyB64, profile?}`. `profile` is optional — the
+connector stamps it when NAS resolves the target profile for a Team-Gateway
+interaction; omitting it (single-profile gateways) preserves legacy routing to
+the default `agent:main` session namespace, mirroring the `profile` field the
+`inbound` frame's `SessionSource` already carries (#60586). The body is
+base64-encoded so arbitrary bytes survive the newline-delimited-JSON transport;
+the gateway base64-decodes
 back to the exact bytes the connector forwarded (the connector already verified
 the provider signature and stripped any shared-identity credential at the edge —
 §6 — so the gateway re-processes a sanitized, token-free body and acts on it via