Address PR review: fix Spaces link and clarify differential token capabilities

- Drop trailing slash on /docs/spaces link in echo channel option page
- Rewrite "differential token capabilities on a single channel" example to
  actually use a single channel, split across publisher/subscriber tokens

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: sacOO7

src/pages/docs/channels/options/echo.mdx

@@ -3,7 +3,7 @@ title: Echo
 meta_description: "The echo channel option enables per-channel control over whether a client receives its own published messages."
 ---
 
-By default, clients receive their own messages when subscribed to a channel they publish on. This is useful in many applications because it means every subscriber, including the publisher, renders state from the same stream of messages. For example, in a [chat application](/docs/chat) or [collaborative editor](/docs/spaces/), a client can publish a message and then update its UI only when that message arrives back on the channel, guaranteeing that all participants see the same ordering and state.
+By default, clients receive their own messages when subscribed to a channel they publish on. This is useful in many applications because it means every subscriber, including the publisher, renders state from the same stream of messages. For example, in a [chat application](/docs/chat) or [collaborative editor](/docs/spaces), a client can publish a message and then update its UI only when that message arrives back on the channel, guaranteeing that all participants see the same ordering and state.
 
 However, this is not always desirable. A client streaming pricing updates, publishing telemetry data, or sending tokens via [AI Transport](/docs/ai-transport) does not need to hear its own messages echoed back. Suppressing echo on these channels reduces unnecessary bandwidth and message processing.
 

src/pages/docs/presence-occupancy/presence.mdx

@@ -661,12 +661,23 @@ For servers:
 ```
 </Code>
 
-Another approach is to use differential token capabilities on a single channel. The following example shows capabilities where clients can enter presence and publish, but only have subscribe access to regular messages:
+Another approach is to issue different tokens for the same channel, each with its own capabilities. For example, one token grants publish and presence access, while a separate token grants presence, history, and subscribe access:
+
+Publisher token:
+
+<Code>
+```json
+{
+  "my-channel": ["publish", "presence"]
+}
+```
+</Code>
+
+Subscriber token:
 
 <Code>
 ```json
 {
-  "presenceChannel": ["publish", "presence"],
   "my-channel": ["presence", "history", "subscribe"]
 }
 ```