docs(02-08): confirm Cloud first-visit regression closed — 5/5 verified

Updates the Task 3 checkpoint follow-up addendum: the content.browse-peer
concurrency-cap fix (8fe6217b) resolved what the fresh-mount guard
(e1a3f31a) alone did not. Instrumentation showed 13 of 14 concurrent
browse-peer calls never settling; capping the fan-out at 3 concurrent
with a 10s per-call timeout eliminated the hang. Verified 5/5 fresh
sessions navigate cleanly on first folder click against the redeployed
build, zero in-flight requests after 15s on Cloud, and a previously-
hung route chunk import now resolves in 17ms.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.planning/phases/02-ui-performance/02-FINDINGS.md

@@ -326,9 +326,9 @@ standing direction; this addendum records the investigation and its outcome.
 
 ### Real-node phase-2 regression: first visit to Cloud, no folder opened on click
 
-**Confirmed, root-caused, partially fixed, not yet fully resolved.** Reproduced deterministically
-on archi-dev-box (both `chrome-headless-shell` and full Chromium — not a test-harness artifact)
-with a genuinely fresh session.
+**Confirmed, root-caused, and fixed — verified 5/5 fresh sessions against the redeployed build.**
+Reproduced deterministically on archi-dev-box (both `chrome-headless-shell` and full Chromium —
+not a test-harness artifact) with a genuinely fresh session.
 
 - The reported symptom ("clicking a folder does nothing") is a **downstream effect**, not a
   click or router bug. Direct instrumentation proved: the click event fires (confirmed via a
@@ -347,29 +347,41 @@ with a genuinely fresh session.
   Once that one request is stuck, Chromium's per-origin connection pool appears to starve every
   other same-origin fetch for the rest of the session, including the lazy chunks any later
   navigation needs.
-- **Fix applied** (`fix(02-08)`, commit `e1a3f31a`, `neode-ui/src/views/Cloud.vue`): gave
+- **Fix #1 applied** (`fix(02-08)`, commit `e1a3f31a`, `neode-ui/src/views/Cloud.vue`): gave
   `Cloud.vue`'s `syncOnEntry()` the same fresh-mount guard already used in
   `Home.vue`/`Web5.vue`/`Mesh.vue`/`Server.vue` (02-04 exempted Cloud on the reasoning each
   individual resource is staleness/inflight-deduped — true per-resource, but the two back-to-back
   `onMounted`+`onActivated` passes still doubled `loadPeerFiles()`'s full per-peer
   `content.browse-peer` fan-out in the same tick, stacking on whatever else was mounting at the
-  same first-activation instant). Tested (95 files/774 tests green, type-check and build clean),
+  same first-activation instant). This reduced but did not eliminate the hang (re-reproduced 5/5
+  against the redeployed build) — ruled out a `chrome-headless-shell`-only artifact (reproduces
+  in full Chromium too) and raw request concurrency alone (an artificial 30-concurrent-request
+  burst against the same `/Photos` endpoint, done outside Cloud.vue, completed in 179ms, no hang).
+- **Root cause fully isolated via direct instrumentation** (request-lifecycle tracking of every
+  `content.browse-peer` call during a fresh Cloud mount): **13 of 14** concurrent
+  `content.browse-peer` requests never settled at all within 15s+ (only the one peer that was
+  actually reachable resolved, in 1.4s). `loadPeerFiles()` fanned these out with **zero
+  concurrency cap** and a 30s per-call timeout — that many simultaneously open, indefinitely-
+  pending same-origin requests (dead/unreachable peers, no server-side timeout on that RPC path)
+  is what starved Chromium's connection pool, not raw request volume in general.
+- **Fix #2 applied** (`fix(02-08)`, commit `8fe6217b`, `neode-ui/src/views/Cloud.vue`): capped the
+  `content.browse-peer` fan-out at 3 concurrent requests (`BROWSE_PEER_CONCURRENCY`, a
+  queue/worker pool) and shortened each call's timeout from 30s to 10s
+  (`BROWSE_PEER_TIMEOUT_MS`), mirroring `PeerFiles.vue`'s existing `PREVIEW_CONCURRENCY` pattern
+  already in this codebase for the identical class of problem (`content.preview-peer`'s own
+  fan-out). A timed-out/failed peer already resolved silently through `resources.ts`'s own
+  error-state path (no throw, no toast) — confirmed unchanged; the muted "N peers unreachable —
+  showing what answered" line is still the only surface, no new UI. Tested (95 files/774 tests
+  green, type-check and build clean, `keepAliveTabs.test.ts` structural assertions untouched),
   committed, pushed, redeployed to archi-dev-box the same way as Task 1.
-- **This fix reduces one genuine, real defect but did NOT fully resolve the reported symptom** —
-  re-reproduced deterministically (5/5 fresh sessions) against the redeployed, fixed build.
-  Ruled out via direct testing before concluding this: not a `chrome-headless-shell`-only
-  artifact (reproduces in full Chromium too); not explained by raw request concurrency alone (an
-  artificial 30-concurrent-request burst against the same `/Photos` endpoint, done outside
-  Cloud.vue, completed in 179ms with zero hang). The precise remaining trigger was not isolated
-  in the time available — the next-most-likely candidate is `loadPeerFiles()`'s unbounded
-  `content.browse-peer` fan-out (one RPC per connected peer, fired with zero concurrency limit,
-  unlike `countsResource`'s own resources.ts-level inflight dedup), worth checking with a bounded
-  test node population and/or a request-concurrency cap.
-- **This remains open.** Flagging here rather than closing it out: a genuine, reproducible,
-  real-hardware defect exists in Cloud.vue's first-activation request burst; the fix committed
-  in this plan narrows it but a further investigation/fix is still needed. Does not block this
-  plan's own Task 3 pass-bar judgment (the user's "otherwise much better" call already accounts
-  for it as a known, separately-reported issue), but should not be considered closed.
+- **Verified resolved**: 5/5 fresh sessions (brand-new browser context each run, no shared
+  storage) now navigate cleanly on the first folder click, confirmed both by URL and by the
+  folder's content actually rendering. Directly re-confirmed the mechanism is closed: zero
+  in-flight (hung) requests after 15s on the Cloud tab (previously exactly one, permanently
+  pending), and a lazy route chunk (`Fleet-*.js`) that previously hung forever now imports in
+  17ms after the same 15s dwell on Cloud.
+- **Closed.** Both contributing defects (the redundant dual-fire pass, and the unbounded/
+  unbounded-duration peer fan-out) are fixed and independently verified on real hardware.
 
 ### Classification of the other three reported issues — all pre-existing, none phase-2