feat: add comprehensive training documentation for _Executable class

Signed-off-by: MontyPokemon <59332150+MonaaEid@users.noreply.github.com>

Author: MonaaEid

docs/sdk_developers/training/executable.md

@@ -10,7 +10,7 @@
 - [Logging & Debugging](#logging--debugging)
 - [Practical Examples](#practical-examples)
 
-## 📋Introduction to _Executable
+## Introduction to _Executable
  * The _Executable class is the backbone of the Hedera SDK execution engine. It handles sending transactions and queries, retry logic, error mapping, and logging, allowing child classes (like Transaction and Query) to focus on business logic.
 
 ```mermaid
@@ -24,7 +24,7 @@ graph TD;
 ```
 
 
-## ▶️⚙️Execution Flow
+## Execution Flow
 
 -How _execute(client) works in the Hedera SDK?
 
@@ -48,7 +48,7 @@ Here’s how child classes hook into the execution pipeline:
 | `_map_response(response, node_id, proto_request)` | Convert the raw gRPC/Proto response into the SDK’s response type (e.g., TransactionResponse, Query result) that gets returned to the caller. |
 
 
-## 🔁Retry Logic
+## Retry Logic
  - Core Logic:
   1. Loop up to max_attempts times — The outer for loop tries the operation multiple times
   2. Exponential backoff — Each retry waits longer than the previous one
@@ -61,7 +61,7 @@ Here’s how child classes hook into the execution pipeline:
 **_Retry logic = Try the operation, wait progressively longer between attempts, pick a different node if needed, and give up after max attempts. This makes the system resilient to temporary network hiccups._**
 
 
-## ⏳Exponential backoff
+## Exponential backoff
 Key Steps:
 
  * First retry: wait `_min_backoff` ms
@@ -88,7 +88,7 @@ Key Steps:
 
   _(If the [gRPC](https://en.wikipedia.org/wiki/GRPC) call itself fails, switch to a different network node and retry.)_
 
-## 🚨Error Handling
+## Error Handling
 
  * Mapping network errors to Python exceptions
  Abstract method that child classes implement:
@@ -125,7 +125,7 @@ Key Steps:
 
 
 
-## ⚠️🐞Logging & Debugging
+## Logging & Debugging
 
 - Request ID tracking
   * Unique request identifier per operation:
@@ -156,11 +156,12 @@ Key Steps:
    )
   ```
   * During gRPC call:
-  ```
+  ```python
   logger.trace("Executing gRPC call", "requestId", self._get_request_id())
   ```
   * After response received:
-  ```logger.trace(
+  ```python
+    logger.trace(
     f"{self.__class__.__name__} status received",
     "nodeAccountID", self.node_account_id,
     "network", client.network.network,          # Network name (testnet, mainnet)
@@ -170,7 +171,8 @@ Key Steps:
   ```
 
   * Before backoff/retry:
-  ```logger.trace(
+  ```python
+    logger.trace(
     f"Retrying request attempt",
     "requestId", request_id,
     "delay", current_backoff,                    # Milliseconds to wait
@@ -180,15 +182,17 @@ Key Steps:
   time.sleep(current_backoff * 0.001)              # Convert ms to seconds
   ```
   * Node switch on gRPC error:
-  ```logger.trace(
+  ```python
+    logger.trace(
     "Switched to a different node for the next attempt",
     "error", err_persistant,
     "from node", self.node_account_id,           # Old node
     "to node", node._account_id                  # New node
   )
   ```
   * Final failure:
-  ```logger.error(
+  ```python
+    logger.error(
     "Exceeded maximum attempts for request",
     "requestId", self._get_request_id(),
     "last exception being", err_persistant
@@ -197,7 +201,7 @@ Key Steps:
 
 - Tips for debugging transaction/query failures
 1. Enable Trace Logging
- Capture detailed execution flow:
+ * Capture detailed execution flow:
  ```python
  client.logger.set_level("trace")  # or DEBUG
  ```
@@ -231,7 +235,8 @@ Execution State Flow:
 
 3. Track Backoff Progression
  Exponential backoff indicates retryable errors:
- ```Attempt 1: (no backoff, first try)
+ ```text
+  Attempt 1: (no backoff, first try)
   Attempt 2: delay 250ms
   Attempt 3: delay 500ms
   Attempt 4: delay 1000ms (1s)
@@ -246,7 +251,7 @@ Execution State Flow:
    * => Fails immediately (no backoff): Permanent error(precheck/validation)
 4. Monitor Node Switches
 Watch for node switching patterns in logs:
-  ```
+  ```text
   Switched to a different node
   from node: 0.0.3
   to node: 0.0.4
@@ -263,12 +268,13 @@ Problem patterns:
 
 5. Cross-Reference Transaction ID with Hedera Explorer
   For transactions, use the transaction ID to verify on the network:
- ```# From logs, capture txID
- txID: "0.0.123@1702057234.567890123"
+  ```
+  # From logs, capture txID
+  txID: "0.0.123@1702057234.567890123"
 
- # Query Hedera mirror node
- curl https://testnet.mirrornode.hedera.com/api/v1/transactions/0.0.123-1702057234-567890123
- ```
+  # Query Hedera mirror node
+  curl https://testnet.mirrornode.hedera.com/api/v1/transactions/0.0.123-1702057234-567890123
+  ```
  What you'll find:
  * => Actual execution result on the network
  * => Receipt status
@@ -287,13 +293,18 @@ Problem patterns:
 
 7. Practical Debugging Workflow
   * Step 1: Capture the request ID
-   `From error output: requestId = TransferTransaction:1702057234567890123`
+   ```
+   From error output: requestId = TransferTransaction:1702057234567890123
+   ```
 
   * Step 2: Search logs for that request ID
-   ```grep "1702057234567890123" application.log```
+   ```text
+   grep "1702057234567890123" application.log
+   ```
 
   * Step 3: Analyze the sequence
-   ```[TRACE] Executing attempt=1 nodeAccountID=0.0.3 ...
+   ```
+    [TRACE] Executing attempt=1 nodeAccountID=0.0.3 ...
     [TRACE] Executing gRPC call ...
     [TRACE] Retrying request delay=250ms ...
     [TRACE] Executing attempt=2 nodeAccountID=0.0.4 ...