Store browser session presence in Forge's Redis cache

[cstns]

Third-party MCP agents need to discover a user's active browser tabs and their context in order to target in-flight requests. The current design in FlowFuse/engineering#233 has a thin TTL map on the gateway, but that's not sufficient. The gateway needs the full context payload (equivalent to contextStore.expert) to reconstitute in-flight MQTT topics with the correct entityType/entityId, and third-party agents need the same context the first-party agent gets.

Backend

Introduce a new cache bucket using the existing Redis cache driver (forge/caches/), keyed per user + session, to store browser session state. Per-field TTL auto-expires entries when heartbeats stop (browser crash, network drop). Forge does not relay presence to the gateway. The gateway retrieves sessions via a platform automation call to Forge when needed.

The backend exposes two endpoints:

• A heartbeat endpoint that extends TTL and accepts visibility/focus state
• A context update endpoint that accepts the full contextStore.expert payload on route changes

Frontend

Sessions are not registered automatically on tab load. The user must explicitly opt in via the MCP header button (#8159). The presence lifecycle is driven by the button toggle, not the team lifecycle.

Once opted in, the frontend should use the existing subscriber pattern (frontend/src/subscribers/) to manage the presence lifecycle. A new subscriber would:

• Start/stop when the user toggles the MCP button on/off
• Use the transport layer and subscriber factory/registry for singleton management
• Send periodic heartbeats (~45s) carrying current visibility/focus state (document.visibilityState, document.hasFocus())
• Watch for Vue Router navigation changes and push updated context to Forge immediately (event-driven, not polled)
• Clear the session on tab close (beforeunload), component unmount, or when the user toggles the MCP button off

Depends on #8157.