fix(02-08): Cloud.vue fresh-mount guard — first-visit connection-pool stall

User-reported checkpoint regression: on a genuinely first visit to Cloud
this session, no folder opened on click (subsequent visits fine).
Root-caused on archi-dev-box, not guessed:

- The click DID register (confirmed via a direct DOM listener) and DID
  call router.push (confirmed by patching the live router instance) —
  but the push's promise never settled, because Vue Router awaits the
  target route's async component, and that dynamic import() itself
  never resolved.
- Confirmed via a manual import() from the page console: importing ANY
  lazy route chunk (Fleet, CloudFolder, AppDetails — unrelated views)
  hangs identically after visiting Cloud once, but works instantly
  before ever visiting Cloud. Not chunk-specific, not router-specific.
- Traced to exactly one permanently-pending network request: a File
  Browser `GET /app/filebrowser/api/resources/Photos` call from Cloud's
  own onMounted burst, confirmed hung via request-lifecycle tracking
  (never finishes or fails, still pending after 10s). The identical
  request, issued manually with a fresh token outside of Cloud.vue,
  returns in 29ms — ruling out the backend/File Browser itself.
- Mechanism: Cloud.vue's syncOnEntry() (loadCounts/loadPeers/
  loadPeerFiles) fires from BOTH onMounted and onActivated with no
  fresh-mount guard (02-04 exempted it, reasoning each resource is
  individually staleness/inflight-deduped — true per-resource, but the
  two back-to-back passes still double the concurrent request volume
  at the single riskiest instant in a session: first KeepAlive
  activation, stacked on whatever other cached view's own onMounted
  burst is firing at the same moment). On real hardware that volume
  was enough to leave one File Browser request stuck, which then
  starves Chromium's per-origin connection pool — breaking every
  subsequent same-origin fetch, including the lazy chunk any later
  navigation needs. Not a router or click-handler bug; the click and
  push both worked correctly the whole time.

Fix: give Cloud.vue the same fresh-mount guard already used in
Home.vue/Web5.vue/Mesh.vue/Server.vue (skip onActivated's redundant
first-activation re-fire since onMounted just ran it). Removes the
duplicate-burst mechanism without changing steady-state reactivation —
onActivated still re-syncs normally on every later KeepAlive round-trip.
No visual/behavioral change (D-01 rule).

Full test suite green (95 files / 774 tests), type-check and build clean.

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

neode-ui/src/views/Cloud.vue

@@ -963,9 +963,31 @@ function loadCounts() {
 // own comment and by CloudPeersRefresh.test.ts, which mounts this view bare)
 // — Vue only fires it automatically on first mount for a component that
 // already has a KeepAlive ancestor. onMounted guarantees this still runs
-// once for a bare mount; the harmless extra pass onActivated makes on a
-// KeepAlive-wrapped first mount is absorbed by the staleness/inflight guards
-// above.
+// once for a bare mount.
+//
+// 02-08 fix (real-hardware regression, not merely a "harmless extra pass"):
+// individually each of loadCounts/loadPeers/loadPeerFiles is staleness- or
+// inflight-deduped, so the ORIGINAL 02-04 assumption that firing this twice
+// back-to-back is free held up per-resource. But the two back-to-back calls
+// still fire loadPeerFiles's full content.browse-peer fan-out (one RPC per
+// connected peer) essentially twice in the same tick before either pass's
+// results land, and layered on top of whatever other KeepAlive-cached view
+// happened to be mounting/activating at the same moment (Home/Server's own
+// onMounted bursts), this measurably doubles the concurrent same-origin
+// request volume at the single riskiest instant in the session — first
+// activation. On archi-dev-box that volume was large enough to leave one
+// in-flight File Browser request permanently stuck (never resolving,
+// confirmed via direct reproduction), which then starved the browser's
+// per-origin connection pool and silently broke every subsequent
+// same-origin fetch for the rest of the session, including the lazy route
+// chunks any later tab/folder navigation needs — "no folders open on
+// click" was a downstream symptom of that stall, not a router or click-
+// handler bug. A fresh-mount guard (the same pattern already used in
+// Home.vue/Web5.vue/Mesh.vue/Server.vue) removes the redundant duplicate
+// pass on first activation without changing steady-state reactivation
+// behavior at all: onActivated still re-syncs normally on every later
+// KeepAlive round-trip, exactly as before.
+let cloudFreshMount = true
 async function syncOnEntry() {
   loadCounts()
   await loadPeers()
@@ -975,7 +997,10 @@ async function syncOnEntry() {
   void loadPeerFiles()
 }
 onMounted(() => { void syncOnEntry() })
-onActivated(() => { void syncOnEntry() })
+onActivated(() => {
+  if (cloudFreshMount) { cloudFreshMount = false; return }
+  void syncOnEntry()
+})
 
 // File Browser can finish its startup scan after we mount — pick counts up
 // the moment it becomes available instead of showing a permanent blank.