Update documentation for new ping/repeat listener flow and 10s RX window

- Updated STATUS_MESSAGES.md: Changed RX window duration from 7s to 10s
- Deprecated "Posting to API" status message (now suppressed from UI)
- Added new "Error: API post failed" status message documentation
- Updated em dash timing (appears after RX window, not after API post)
- Updated slot revocation flow to reflect background API posting
- Added comprehensive "Ping/Repeat Listener Flow" section to CONNECTION_WORKFLOW.md
- Documented old vs new flow comparison with benefits and timing analysis
- Updated all references to reflect asynchronous API posting behavior

Co-authored-by: MrAlders0n <55921894+MrAlders0n@users.noreply.github.com>

Author: Copilot

docs/CONNECTION_WORKFLOW.md

@@ -313,14 +313,15 @@ When a wardriving slot is revoked during an active session (detected during API
 **Revocation Sequence:**
 
 1. **Detection**
-   - During "Posting to API" operation
+   - During background API POST operation (runs asynchronously after RX window)
    - API returns `{"allowed": false, ...}`
    - Detected in `postToMeshMapperAPI()` response handler
 
 2. **Initial Status**
    - **Dynamic Status**: `"Error: Posting to API (Revoked)"` (red)
    - Sets `state.disconnectReason = "slot_revoked"`
    - Visible for 1.5 seconds
+   - **Note**: User may already be seeing "Idle" or "Waiting for next ping" before this error appears (because API runs in background)
 
 3. **Disconnect Initiated**
    - Calls `disconnect()` after 1.5s delay
@@ -334,16 +335,23 @@ When a wardriving slot is revoked during an active session (detected during API
    - **Dynamic Status**: `"WarDriving slot has been revoked"` (red, terminal - NO "Disconnected:" prefix)
    - This is the final terminal status
 
-**Complete Revocation Flow:**
+**Complete Revocation Flow (Updated for background API posting):**
 ```
 Connection Status: (unchanged) → "Disconnecting" → "Disconnected"
-Dynamic Status: "Posting to API" → "Error: Posting to API (Revoked)" → "—" → "WarDriving slot has been revoked"
+Dynamic Status: "Idle"/"Waiting for next ping" → "Error: Posting to API (Revoked)" → "—" → "WarDriving slot has been revoked"
 ```
+**Timeline:**
+- T+0s: RX window completes, status shows "Idle" or "Waiting for next ping", next timer starts
+- T+0-3s: Background API post running (3s delay, then POST) - silent
+- T+3-4s: Revocation detected, "Error: Posting to API (Revoked)" shown (1.5s)
+- T+4.5s: Disconnect initiated
+- T+5s: Terminal status "WarDriving slot has been revoked"
 
 **Key Differences from Normal Disconnect:**
 - Normal disconnect: Dynamic Status shows `"—"` (em dash)
 - Revocation: Dynamic Status shows `"WarDriving slot has been revoked"` (red error, no prefix)
 - Revocation shows intermediate "Error: Posting to API (Revoked)" state
+- With the new ping/repeat flow, revocation may be detected after user already sees "Idle" or "Waiting for next ping" (because API runs in background)
 
 ## Workflow Diagrams
 
@@ -590,6 +598,120 @@ stateDiagram-v2
 - Error → Disconnected
 - Recovery always possible
 
+## Ping/Repeat Listener Flow
+
+### Overview
+
+The ping/repeat listener flow manages the complete lifecycle of a wardrive ping operation, from sending the ping to listening for repeater echoes to posting data to the MeshMapper API.
+
+**Key Design Change (v1.4.2+):** API posting now runs in the background (asynchronously) to prevent blocking the main ping cycle. This allows the next ping timer to start immediately after the RX listening window completes, without waiting for the API POST to finish.
+
+### New Ping/Repeat Flow (v1.4.2+)
+
+```
+┌─────────────────────────────────────────────────────────────────────┐
+│ 1. Ping Sent                                                        │
+│    - Send ping to mesh network                                      │
+│    - Start repeater echo tracking                                   │
+│    - Show "Ping sent" status                                        │
+│    - Lock ping controls                                             │
+└──────────────────────────────┬──────────────────────────────────────┘
+                               │
+                               ▼
+┌─────────────────────────────────────────────────────────────────────┐
+│ 2. RX Listening Window (10 seconds)                                 │
+│    - Listen for repeater echoes                                     │
+│    - Show "Listening for heard repeats (Xs)" countdown              │
+│    - Track all repeaters that forward the ping                      │
+│    - Update session log in real-time                                │
+└──────────────────────────────┬──────────────────────────────────────┘
+                               │
+                               ▼
+┌─────────────────────────────────────────────────────────────────────┐
+│ 3. RX Window Complete - IMMEDIATE ACTIONS                           │
+│    - Stop RX listening countdown                                    │
+│    - Finalize heard repeats (stop tracking)                         │
+│    - Update UI log with final repeater data                         │
+│    - **Unlock ping controls** ← NEW: Don't wait for API             │
+│    - **Start next ping timer** ← NEW: Don't wait for API            │
+│    - **Set status to "Idle"/"Waiting for next ping"**               │
+└──────────────────────────────┬──────────────────────────────────────┘
+                               │
+                               ▼
+┌─────────────────────────────────────────────────────────────────────┐
+│ 4. Background API Posting (Async, Non-Blocking)                     │
+│    - Delay 3 seconds (silent, no status message)                    │
+│    - POST ping data to MeshMapper API                               │
+│    - **Success**: Silent (no UI notification)                       │
+│    - **Error**: Show "Error: API post failed"                       │
+│    - Refresh coverage map after POST completes                      │
+└─────────────────────────────────────────────────────────────────────┘
+```
+
+### Key Changes from Previous Flow (v1.4.1 and earlier)
+
+**Old Flow:**
+1. Ping sent
+2. Listen for repeats (7 seconds)
+3. **Wait for API post to complete** (3s delay + POST time)
+4. **Then** unlock controls and start next timer
+5. Status: "Ping sent" → "Listening (7s)" → "Posting to API" → "Idle"/"Waiting"
+
+**New Flow:**
+1. Ping sent
+2. Listen for repeats (10 seconds) ← **Increased from 7s to 10s**
+3. **Immediately** unlock controls and start next timer ← **Key change**
+4. **Background** API post (silent on success, error only if fails)
+5. Status: "Ping sent" → "Listening (10s)" → "Idle"/"Waiting" ← **No "Posting to API"**
+
+### Benefits
+
+1. **Faster cycle times**: Next ping can start immediately after 10s RX window, not waiting for API
+2. **Better UX**: User sees smooth progression without API delays blocking the UI
+3. **More repeater data**: 10-second listen window (vs 7s) captures more mesh echoes
+4. **Cleaner UI**: API success messages suppressed, only errors shown
+5. **Non-blocking**: API failures don't stall the ping cycle
+
+### Implementation Details
+
+**Functions:**
+- `postApiInBackground(lat, lon, accuracy, heardRepeats)` - New async function for background API posting
+- `sendPing(manual)` - Refactored to start next timer immediately after RX window
+- `RX_LOG_LISTEN_WINDOW_MS` - Increased from 7000ms to 10000ms
+
+**Error Handling:**
+- API POST failures are caught with `.catch()` handler
+- Error message shown to user: "Error: API post failed"
+- Main ping cycle continues unaffected by API failures
+- Background failures don't crash or stall the application
+
+**Debug Logging:**
+- `[DEBUG] Backgrounding API post for coordinates: ...`
+- `[DEBUG] Starting 3-second delay before API POST`
+- `[DEBUG] 3-second delay complete, posting to API`
+- `[DEBUG] Background API post completed successfully`
+- `[DEBUG] Background API post failed: ...`
+
+### Status Message Behavior
+
+**Visible to User:**
+- "Ping sent" (500ms minimum)
+- "Listening for heard repeats (10s)" (countdown, 10 seconds)
+- "Idle" or "Waiting for next ping (Xs)" (immediately after RX window)
+- "Error: API post failed" (only if background API fails)
+
+**Not Visible (Suppressed):**
+- ~~"Posting to API"~~ - No longer shown for successful API posts
+- API success confirmation - Silent operation
+
+### Timing Analysis
+
+**Total time from ping to next ping (Auto mode, 30s interval):**
+- Old flow: 10s (ping) + 7s (listen) + 3s (delay) + 0.5s (API) + 30s (interval) = ~50.5s between pings
+- New flow: 10s (ping) + 10s (listen) + 30s (interval) = ~50s between pings (API runs in parallel)
+
+**Actual improvement:** Next timer starts ~3.5s earlier (no waiting for API), better responsiveness
+
 ## Passive RX Log Listening
 
 ### Overview

docs/STATUS_MESSAGES.md

@@ -127,20 +127,22 @@ These messages appear in the Dynamic App Status Bar. They NEVER include connecti
 ##### WarDriving slot has been revoked
 - **Message**: `"WarDriving slot has been revoked"`
 - **Color**: Red (error)
-- **When**: During active session, API returns allowed=false during ping posting
+- **When**: During active session, API returns allowed=false during background ping posting
 - **Terminal State**: Yes (persists until user takes action)
-- **Sequence**: 
-  1. "Posting to API" (blue)
-  2. "Error: Posting to API (Revoked)" (red, 1.5s)
-  3. Connection bar: "Disconnecting" → "Disconnected"
-  4. Dynamic bar: "WarDriving slot has been revoked" (terminal)
+- **Sequence** (Updated for background API posting): 
+  1. RX listening window completes → Status shows "Idle" or "Waiting for next ping"
+  2. Background API post detects revocation (silent, no status change yet)
+  3. "Error: Posting to API (Revoked)" (red, 1.5s)
+  4. Connection bar: "Disconnecting" → "Disconnected"
+  5. Dynamic bar: "WarDriving slot has been revoked" (terminal)
+- **Notes**: With the new ping/repeat flow, revocation is detected during the background API post (which runs after the RX window completes and next timer starts)
 
 ##### Error: Posting to API (Revoked)
 - **Message**: `"Error: Posting to API (Revoked)"`
 - **Color**: Red (error)
-- **When**: Intermediate status shown when slot revocation detected during API posting
+- **When**: Intermediate status shown when slot revocation detected during background API posting
 - **Duration**: 1.5 seconds (visible before disconnect begins)
-- **Notes**: First status in revocation sequence, followed by disconnect flow
+- **Notes**: First visible status in revocation sequence, followed by disconnect flow. Appears after background API post detects revocation.
 
 ##### Unable to read device public key; try again
 - **Message**: `"Unable to read device public key; try again"`
@@ -280,7 +282,7 @@ These messages use a hybrid approach: **first display respects 500ms minimum**,
 - **Message**: `"Listening for heard repeats (Xs)"` (X is dynamic countdown)
 - **Color**: Sky blue (info)
 - **When**: After successful ping, listening for repeater echoes
-- **Duration**: 7 seconds total
+- **Duration**: 10 seconds total (changed from 7 seconds)
 - **Minimum Visibility**: 500ms for first message, immediate for countdown updates
 - **Source**: `content/wardrive.js:rxListeningCountdownTimer`
 
@@ -322,22 +324,31 @@ These messages use a hybrid approach: **first display respects 500ms minimum**,
 
 #### 6. API and Map Update Messages
 
-##### Posting to API
+##### Posting to API (DEPRECATED - No longer shown)
 - **Message**: `"Posting to API"`
 - **Color**: Sky blue (info)
-- **When**: After RX listening window, posting ping data to MeshMapper API
-- **Timing**: Visible during API POST operation (3-second hidden delay + API call time, typically ~3.5-4.5s total)
-- **Source**: `content/wardrive.js:postApiAndRefreshMap()`
+- **When**: ~~After RX listening window, posting ping data to MeshMapper API~~ **NO LONGER SHOWN**
+- **Timing**: ~~Visible during API POST operation (3-second hidden delay + API call time, typically ~3.5-4.5s total)~~ **SUPPRESSED**
+- **Notes**: As of the ping/repeat listener refactoring, API posting now runs in the background without showing status messages. Success is silent; only errors are displayed.
+- **Source**: ~~`content/wardrive.js:postApiAndRefreshMap()`~~ Replaced by `postApiInBackground()`
+
+##### Error: API post failed
+- **Message**: `"Error: API post failed"`
+- **Color**: Red (error)
+- **When**: Background API POST fails during asynchronous posting (after RX listening window completes)
+- **Notes**: This is the only API-related message now shown to users during normal ping operations. Success is silent.
+- **Source**: `content/wardrive.js:postApiInBackground()` error handler
 
 ##### — (em dash)
 - **Message**: `"—"` (em dash character)
 - **Color**: Slate (idle)
 - **When**: 
-  - Manual mode after API post completes
+  - Manual mode immediately after RX listening window completes (changed from "after API post completes")
   - After successful connection (shows "Connected" in connection bar)
   - Normal disconnect (shows "Disconnected" in connection bar)
   - Any time there is no active message to display
 - **Purpose**: Placeholder to indicate "no message" state
+- **Notes**: With the new ping/repeat listener flow, the em dash appears immediately after the 10-second RX window, not after API posting (which now runs in background)
 - **Source**: Multiple locations - `content/wardrive.js`
 
 #### 7. Auto Mode Messages