docs(tasks): v3.3.92 decisive instrument + breadth audit (main.js log/progress/IPC + 5 uploaders all clean)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

tasks/todo.md

@@ -66,8 +66,25 @@ from the user's real load, not the sandbox. Per-uploader undici Agent audit: clo
 module-level Agent (connections:50); doodstream/voe/vidmoly use the global dispatcher (pooled per origin, NO
 per-call agent explosion) — so no agent fix needed.
 
+## v3.3.92 — make the single measurement decisive + breadth audit of un-checked main.js hot paths
+Enriched the ELD log line with `process.getActiveResourcesInfo()` as a compact type-histogram:
+`eventloop-delay active=N mean/p99/max/stddev ms threadpool=64 resources=K {TCPSocketWrap:50,FSReqCallback:4,...}`.
+Now ONE run splits all three readings in a single line: high mean/p99 → CPU-blocked (workers/cap);
+low delay + many TCP/FS/GetAddrInfo resources → IO-bound queueing (threadpool/sockets, NOT workers);
+low delay + few resources → not saturated (lag elsewhere / perception). Pure numbers, no redaction surface.
+
+Breadth audit this round (4th /goal re-fire, code I wrote, NOT re-measuring cleared render/persist):
+- main.js logging (debug/rot/upload): all buffered + ASYNC fs.appendFile (write-guard flag, 500ms timer,
+  setImmediate re-flush). Sync appendFileSync ONLY in crash/signal/exit handlers (correct there). CLEAN.
+- main.js progress coalescing (_progressByJob Map + 100ms batch → one upload-progress-batch via safeSend):
+  non-terminal = Map.set (keeps latest/job); gated upstream to 4/sec/job. CLEAN at N=50.
+- _appendJobLog: capped in-memory ring buffer (Map, FIFO-evict). CLEAN.
+- All 5 uploaders: doodstream/voe/vidmoly/clouddrop-simple stream via async createReadStream + for-await +
+  async throttle.consume; clouddrop-chunked now async fh.read. NONE block the main loop per chunk. CLEAN
+  (clouddrop's old readSync was the unique outlier, fixed v3.3.90).
+
 ## NEXT (gated on the real-app ELD number + user's explicit nod)
-User runs their 50-concurrent load once; the `eventloop-delay` log lines decide:
+User runs their 50-concurrent load once; the enriched `eventloop-delay` log line decides:
 - mean/p99 HIGH (tens–hundreds ms) → CPU-blocked → propose worker_threads/child-process upload pool OR a
   smart concurrency cap (WITH the user's nod — it's hard to reverse and touches credentials/abort/rotation).
 - delay LOW while it still lags → IO-bound → threadpool bump already addresses it; if not, look at socket