Make a third-party MCP session id safe for the gateway topic

[cstns]

Closes #8564

_meta["openai/session"] is shaped v1/<token>. The session id becomes one level of the gateway's MQTT topic, so embedding that raw produced a topic with an extra level, which matched no ACL pattern and was denied without raising a validation error. The request never reached the broker or the gateway, and the caller waited out the full 30s proxy timeout before getting a 504. Production showed result: deny in 0.226 ms for those topics while neighbouring UUID-carrying requests from the same user were allowed and completed in ~150 ms.

The fix sanitises that value before it is used. Ids already safe as a topic level pass through untouched, so a well-behaved client's session id stays readable in logs and on the wire. Anything else is replaced with a SHA-256 digest. Hashed rather than stripped for two reasons: stripping would collapse two distinct sessions onto the same topic, and the mapping has to be stable or a pinned browser tab is unreachable between a client's own requests.

Only the _meta value is treated as untrusted. The mcp-session-id header is an id we minted coming back to us, and randomUUID() is ours, so neither is touched. The helper returns null when there is nothing usable, which lets a missing openai/session fall through to a fresh id without an extra branch.

The ACL's session check moves from length (mcpSessionId.length < 8) to format. Worth being precise about what that adds: a slashed id never matched the topic pattern ([^/]+) in the first place, so it was already denied, just silently. The case the format check genuinely catches is something like sess+ion12345, long enough for the old check and a clean match for the topic pattern, but an MQTT wildcard sitting inside a topic level. It is a backstop, not the fix.

Tests: seven on the helper (passthrough, separator, wildcards, stability, distinctness, idempotence, unusable input), two on the route (a slashed openai/session yields a topic-safe id echoed in the response header, and the same value routes identically across two calls), two on the ACL.

One known gap, left deliberately: mcp-session-id is still a client-supplied header, so a client sending mcp-session-id: a/b would rebuild the same broken topic and eat the timeout. That is self-inflicted rather than a security issue, the ACL denies it either way, and the clients actually affected here do not send the header at all.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77.03%. Comparing base (addb6bf) to head (3a3d5aa).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8565      +/-   ##
==========================================
+ Coverage   77.02%   77.03%   +0.01%     
==========================================
  Files         465      466       +1     
  Lines       24923    24934      +11     
  Branches     6636     6638       +2     
==========================================
+ Hits        19197    19208      +11     
  Misses       5726     5726              

Flag	Coverage Δ
backend	77.03% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.