Flaky daemon test: 'verify kubo is running' uses a single un-retried fetch that races the pkc-js kubo restart

[Rinse12]

Symptom

test/cli/daemon.test.ts intermittently fails on ubuntu/macOS at the post-startup "verify kubo is running" step:

FAIL test/cli/daemon.test.ts > bitsocial daemon kills kubo on its own shutdown (no backup /shutdown call)
  > daemon's own cleanup kills kubo after double SIGTERM (impatient user)
TypeError: fetch failed  ->  connect ECONNREFUSED 127.0.0.1:<kuboPort>
  ❯ test/cli/daemon.test.ts:833

Seen on https://github.com/bitsocialnet/bitsocial-cli/actions/runs/27457190762 (both ubuntu and macOS); Windows skips these two tests via skipIf(win32).

Root cause

The two tests in the kills kubo on its own shutdown describe (lines ~793 and ~824) verify kubo with a single, un-retried call right after startPkcDaemonWithDynamicPorts returns:

const kuboRes = await fetch(`${kuboApiUrl}/bitswap/stat`, { method: "POST" });
expect(kuboRes.status).toBe(200);

But startPkcDaemon resolves as soon as the daemon prints its Communities in data path banner — which does not guarantee kubo's HTTP API is currently listening. With pkc-js >=0.0.46, on first connect pkc-js rewrites kubo's Routing config and POSTs /shutdown, so the daemon restarts kubo around init. That leaves a brief window where the kubo API port refuses connections. When the one-shot fetch lands in that window, the test fails. The rest of the suite already avoids this by polling waitForKuboReady.

Fix

Replace the one-shot fetch/expect(200) in both tests with the existing retry helper:

const kuboReady = await waitForKuboReady(kuboApiUrl, 45000);
expect(kuboReady).toBe(true);

Not caused by the #94 daemon-state change — this is a pre-existing test-only flake exposed by the same CI run.

[Rinse12]

Fixed in d06787d (pushed to master). Both kills kubo on its own shutdown tests now use waitForKuboReady instead of a one-shot fetch. Full local test:cli green (39 files, 305 tests); both tests pass.