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

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,18 +661,29 @@ 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:
+A second approach is to split capabilities across two tokens for the same channel. A publisher-role token grants only `publish` and `presence`, so clients using it can enter the presence set and publish messages, but receive nothing back because they lack `subscribe`. A subscriber-role token grants `subscribe` (and `history` if needed) so other clients can read the channel.
+
+Publisher token:
+
+<Code>
+```json
+{
+  "my-channel": ["publish", "presence"]
+}
+```
+</Code>
+
+Subscriber token:
 
 <Code>
 ```json
 {
-  "presenceChannel": ["publish", "presence"],
-  "my-channel": ["presence", "history", "subscribe"]
+  "my-channel": ["history", "subscribe"]
 }
 ```
 </Code>
 
-Alternatively, [channel mode flags](/docs/channels/options#modes) can be used to enable clients to be present on a channel without subscribing to presence events. This also enables clients to still subscribe to regular messages on the channel.
+The `subscribe` capability covers both regular messages and presence state-change messages, so it cannot be used to receive one without the other. To let a single client subscribe to regular messages on a channel while still being present without receiving presence events, use [channel mode flags](/docs/channels/options#modes) instead.
 
 ## External presence set maintenance <a id="external-maintenance"/>