WebRTC: Add objective Chat service: Spaces, sessions, and call timeline

[cool-ant]

This is PR1 in a chin of PRs to release the webrtc work. First phase is the Chat objective service, which handles

• Spaces: generalized term for groups of wrtc clients, commonly called "rooms" in a video conf context. Spaces determine who's allow to connect in a partiuclar instance. In the eventual app, this would be a particular DM pair or a group chat and can involve chat, file sends, and occasional video/audio calls.
• Sessions: media-specific structure for what and who are allowed to do what, e.g., a session for chat, that's associated with a Space.
• Call events: history of connection/call details, which allow for metadata in the UI, e.g., "Missed call", "Called ended".

Architectural Decisions and their Impact

Added in this PR: the Chat package — objective service chat and r-chat. Plugin API included; there is no Homepage UI here.

---

chat is an objective (on-chain) service.
Spaces, session metadata (chat-data / av-call / pair), and call-timeline events live in consensus state. Architectural impact:

1. Membership and session auth are infra-public and durable — who may join a Space/session is agreed across the network, not tied to one node’s memory.
2. Third-party apps can reuse it as shared infra — they don’t need to roll their own “rooms,” session ids, or join-authorization model; they call Chat (e.g. authorizeSessionJoin) and build UX on top.
3. Message and media bodies stay out of this service — Chat owns who’s allowed and call/session history metadata; actual chat bytes and A/V ride peer-to-peer (WebRTC) (later PRs), with subjective signaling (x-wrtcsig -- also future PR) brokering live presence.

In short: Chat (this PR) = objective who’s-allowed / session + call metadata infra; realtime who’s-connected-now comes later as subjective x-wrtcsig.

Summary

• Adds the objective Chat package: DM/group Spaces, WebRTC session metadata (chat-data / av-call / pair sessions), and call-timeline events.
• Exposes plugin APIs (ensure-dm, ensure-group, create-session, close-session, …) and authenticated GraphQL (mySpaces, activeSession, sessionJoinAuth, callEvents, …).
• Wires Chat into package/CMake/ctest so the on-chain model can be built and tested on its own.

Testing locally

via ctest / manual cargo-psibase test

There is no Homepage UI in this PR. Validation is via cargo-psibase test (primary) and optional GraphiQL on a node with Chat installed.

For convenience, here's the ctest command:

cargo-psibase test \
  --manifest-path packages/user/Chat/service/Cargo.toml \
  --target-dir /tmp/psibase-chat-target \
  --psitest=build/psitest

on chain:

On a booted node with the Chat package installed:

• Open https://chat./graphiql authenticated as alice.
• Drive (plugin / push_action / GraphQL as available):
• Alice ensureDm(bob) → Expect: Space id returned.
• Alice createSession(spaceId, purpose: "chat-data"|"av-call") → Expect: session id; participants are the Space members.
• Query mySpaces / activeSession / sessionJoinAuth → Expect: alice↔bob membership and join auth match the Space.

[swatanabe]

I'm confused.

• There is no other purpose
• The only way for DM not to include all space members is to have only one participant. Is that even allowed?

[cool-ant]

hmm, I likely pruned one along the way. Reworded. And DMs now confirm both participatns, so the session memberhsip matches the space membership

[swatanabe]

I don't understand why using the explicit participants list for other purposes is safer. If every existing purpose uses the space members, why would you expect a new purpose to be different? Is the explicit participants list needed at all?