docs: sync from backend ca2b1c4 — marketplace e2e smoke runner

11 - Testing/Concurrency and Performance Profile.md

@@ -36,6 +36,21 @@ Each worker must use unique:
 Notifications are mandatory inside every worker. See
 [[Notification Assertion Procedure]].
 
+Implemented runner:
+
+```bash
+cd ~/CascadeProjects/escrow/backend
+BASE_URL=https://dev.amn.gg \
+PAYMENT_MODE=status \
+CONCURRENCY_LEVELS=1,2,4,8,16,32 \
+ROUNDS=1 \
+bash scripts/smoke/marketplace-e2e-notifications.sh
+```
+
+Use `PAYMENT_MODE=live` for low-concurrency BSC Testnet tUSDT confirmation.
+Use `PAYMENT_MODE=status` for high-concurrency marketplace/notification
+profiling without consuming gas.
+
 ## Ramp Plan
 
 Start with one simultaneous worker and double until a stop condition is reached:
@@ -59,6 +74,7 @@ stage.
 | Mode | Payment behavior | Use |
 |---|---|---|
 | Live-chain mode | Real BSC Testnet tUSDT transfers | Final confidence at low concurrency; expensive/slower; consumes gas. |
+| Status-only smoke mode | Moves accepted request to `payment` through the status route | Implemented high-concurrency marketplace/notification profiling without chain variables. |
 | Scanner fixture mode | Deterministic scanner/balance fixture or controlled test endpoint | High concurrency without chain bottleneck. Must not be enabled in production. |
 | API-only dry run | Runs request/offer/delivery and skips payment finalization | Marketplace/notification profiling without chain variables. |
 
@@ -267,4 +283,3 @@ These are the expectations to validate:
 - Scanner live-chain checks are likely bounded by BSC Testnet RPC latency and should be separated from API-only profiling.
 - Payment intent creation may become slower if destination derivation, token registry lookup, and scanner registration are serial.
 - Socket fanout should be watched at C16+ because each worker has multiple actors and multiple tabs/devices may multiply room membership.
-