fixup! EDU-1469: Re-writes idempotent publishing section to improve clarity to the reader

Author: franrob-projects

content/channels/index.textile

@@ -631,13 +631,13 @@ await channel.publish(name: 'example', data: 'message data');
 
 h3(#idempotency). Idempotent publish
 
-Ably supports idempotent publishing through both REST and realtime methods. This feature prevents the processing or forwarding duplicate messages when publishing the same message multiple times under certain network conditions or due to client reattempts. Idempotent publishing involves associating each message with a unique ID. The system then uses this ID to prevent further processing of any message published again with the same ID, recognizing it as a duplicate.
+Ably supports idempotent publishing through both REST and Realtime methods. This feature prevents the processing or forwarding duplicate messages when publishing the same message multiple times under certain network conditions or due to client reattempts. Idempotent publishing involves associating each message with a unique ID. The system then uses this ID to prevent further processing of any message published again with the same ID, recognizing it as a duplicate. 
 
-Ably's client libraries automatically add IDs to messages to ensure idempotent handling. This functionality applies to both REST and realtime publishing. For library versions older than 1.2, enabling idempotent REST publishing was not the default and required activation using the @idempotentRestPublishing@ "@ClientOptions@":/api/rest-sdk#client-options. However, starting with version 1.2, its enabled by default.
+Ably's SDK automatically add IDs to messages to ensure idempotent handling. This functionality applies to both REST and realtime publishing. For library versions older than 1.2, enabling idempotent REST publishing was not the default and required activation using the @idempotentRestPublishing@ "@ClientOptions@":/api/rest-sdk#client-options. However, starting with version 1.2, its enabled by default. 
 
-In some cases, achieving idempotency requires a client-supplied ID, especially in scenarios where it's impractical to maintain a single continuously active client instance, such as during a publisher restart or when preserving idempotency across an entire message processing pipeline that involves an upstream system using message IDs. In these situations, specifying a custom message ID for REST and realtime publishing maintains idempotency.
+In some cases, achieving idempotency requires a client-supplied ID, especially in scenarios where it's impractical to maintain a single continuously active client instance, such as during a publisher restart or when preserving idempotency across an entire message processing pipeline that involves an upstream system using message IDs. In these situations, specifying a custom message ID for REST and realtime publishing maintains idempotency. 
 
-The following example manually specifies a message ID:
+The following example manually specifies a message ID: 
 
 ```[realtime_javascript]
 const rest = new Ably.realtime.Promise('{{API_KEY}}');
@@ -684,7 +684,7 @@ A client can subscribe to all messages published to a channel by passing a block
 A client can subscribe to all messages published to a channel by passing a lambda expression to the @Subscribe()@ method. The lambda is passed a "@Message@":/api/realtime-sdk/types#message object for each message are received. Alternatively, a client can listen for a subset of messages based on the name of the published message.
 </div>
 
-The following is an example of registering a listener for all messages:
+The following is an example of registering a listener for all messages: 
 
 ```[realtime_javascript]
 const realtime = new Ably.Realtime.Promise('{{API_KEY}}');