feat: expand MQTT contract and reliability lessons

lessons/09-sessions-recovery.md

@@ -6,7 +6,11 @@ Run all commands from `/home/ryan/Media/Code/Code/robot-market/mqtt-5-learning`.
 
 ## A connection is temporary; a session may outlive it
 
-The network connection carries packets now. A broker session can preserve subscriptions and eligible pending deliveries after that connection closes. Your Go command map lives in a different place and is not restored by CONNACK.
+**❓ Question:** **The simulator loses its network connection after subscribing. What must still exist for a queued ping to reach it when it reconnects?**
+
+**💬 Answer:** The simulator must reconnect with the same Client ID to a broker session that still exists, and that session must contain its QoS 1 subscription. The backend's PUBACK only confirms the broker accepted that publication on this hop; it does not prove the simulator received or completed the ping. Your Go command map lives in a different place and is not restored by CONNACK.
+
+The network connection carries packets now. A broker session can preserve subscriptions and eligible pending deliveries after that connection closes.
 
 | Clean Start on this connection | Prior unexpired session under the same Client ID | Expected Session Present | Meaning |
 | --- | --- | --- | --- |
@@ -20,6 +24,10 @@ In AutoPaho v0.23.0, `CleanStartOnInitialConnection` affects the manager's first
 
 ### Work through an offline command
 
+**❓ Question:** **Why does a new Client ID not receive the offline ping sent for the old simulator ID?**
+
+**💬 Answer:** Client ID selects the broker session. A new ID starts or resumes a different session, so it has no old subscription or queued delivery. A `device_id` in the payload is only an application claim and does not select or authenticate a broker session.
+
 At t=0 the simulator has subscribed at QoS 1 with expiry 60. At t=5 it disconnects. At t=10 the backend publishes a nonretained QoS 1 ping. At t=20 the same simulator ID reconnects with Clean Start false. Assuming the broker retained the session, accepted the publication, and no shorter message expiry or resource limit intervened, the subscription allows queued delivery. Reconnect after the session expires and the old queue is gone.
 
 Creating a new subscriber after publication is different: it had no prior subscription/session to receive that queued nonretained message. Retained state, studied next, is associated with a topic and can initialize a new subscriber.
@@ -44,6 +52,10 @@ Not necessarily. The broker resumed its session while the backend's in-memory ap
 
 ## 1. Add session controls
 
+**❓ Question:** **What does `Session Present` tell you after CONNACK, and what does it leave unknown?**
+
+**💬 Answer:** It reports whether the broker resumed prior session state for this connection. It does not report whether the backend's command record survived, whether a device acted, or whether every queued application job completed.
+
 Extend the typed configuration with Clean Start and Session Expiry Interval in seconds, and pass them into AutoPaho. Edit `internal/mqtt/client.go` to log `SessionPresent` from CONNACK without logging credentials. Record connection and subscription readiness separately. Read the pinned `autopaho/auto.go`: `CleanStartOnInitialConnection` applies to the first connection of that manager; automatic reconnects behave differently from constructing a new manager.
 
 Use unique stable IDs for backend and simulator. Run one process per client ID. A changing ID creates a different session, while simultaneous clients sharing an ID can take over each other's connection.