Flake: profile-sync e2e — CAR pin recovery returns 0 tokens (helia.pins.add can't load block)

[vrogojin]

Symptom

`tests/e2e/profile-sync.test.ts` > `Profile (OrbitDB + IPFS) Sync E2E` > `ProfileTokenStorageProvider pins real tokens to a CAR and recovers them on a fresh load` fails reproducibly against real testnet:

```
FAIL tests/e2e/profile-sync.test.ts:375
AssertionError: expected 0 to be greater than or equal to 1000
expect(recoveredBal.total).toBeGreaterThanOrEqual(MIN_CONFIRMED);
```

(`MIN_CONFIRMED = 1_000n` smallest-unit USDU.)

Caught during the post-merge full-suite rerun on the issue-42 branch (sphere-sdk PR #415). Unrelated to that PR — present on `main` too.

Reproduction

```
cd sphere-sdk
npx vitest run --config vitest.e2e.config.ts tests/e2e/profile-sync.test.ts -t "ProfileTokenStorageProvider pins real tokens"
```

Real testnet (`goggregator-test.unicity.network`, `nostr-relay.testnet.unicity.network`, and the configured IPFS gateways).

What the log says

Throughout the test, every CAR pin attempt by the local Helia node fails to load the block from the network:

```
[ProfilePinShim] helia.pins.add failed for bafyreicmoschpxu…: Failed to load block for bafyreidbrrv5stpow2fiqflqnzirritv72xmavpiylss77ks3zenhtex2e
[ProfilePinShim] helia.pins.add failed for bafyreibhpjgbvli…: Failed to load block for bafyreidy3ft3skqu5gwvqgsh5cgmmc3cswucqns7xa5eukohixzumctyk4
[ProfilePinShim] helia.pins.add failed for bafyreigodcc7zxh…: Failed to load block for bafyreigkws3jvu4bxd77yhbfrpnphrjwsei5agxemzvrpf4r7zk3h26uc4
(... 20+ similar lines ...)
```

Then the test wipes local storage, re-imports the mnemonic, and the post-import sync surfaces zero tokens — no surprise, since the CAR was never durably pinned.

Probable root cause

The Helia node attempting the pin can't fetch the block from the IPFS network. Possible causes (need triage):

1. HTTP-only Helia regression / config drift. Per memory `project_issue_266_design` and `project_issue_239_followup`, the post-Client-side Helia/libp2p bootstrap is too heavy — clients should HTTP-only to operator Kubo gateway(s) #266 default is HTTP-only IPFS with a local FsBlockstore. If the Helia spawn in this test setup somehow still tries libp2p / DHT discovery against a peer that doesn't have the block, the pin call fails. Verify the Helia config the test environment hands to `ProfilePinShim`.
2. Gateway lag. Per `project_issue_234_findings`, the dominant cause of the post-PR-fix(profile)(#234): destroy ordering — partial fix + diagnostic test #235 IPFS pin propagation failures was HTTP-pin gateway lag and the fix was local-Helia blockstore. If the gateway list this test resolves against still has stale propagation, the same lag shows up.
3. Flush durability gate. Per `project_issue_268_findings`, the 30 s HEAD-check deadline in `lifecycle-manager.ts` can time out under contended testnet — not necessarily fatal here, but worth checking the verify-gate state when the pin attempts fail.

Out of scope for this issue

• The companion legacy-path failure in `tests/e2e/wallet-lifecycle.test.ts` ("recovers L3 tokens via IPFS after wallet destruction and re-import"). That's the deprecated `IpfsStorageProvider` (IPNS-based) path. Skipped on `fix/issue-42-nametag-publish-out-of-band` (commit pending).

Suggested investigation order

1. Add a one-shot log dump from `ProfilePinShim` capturing the Helia config (HTTP-only flag, bootstrap peers, blockstore type) on first failure.
2. Repro with `UNICITY_API_KEY` set + the production gateway list, then with a single explicit local Helia + FsBlockstore — see which one succeeds.
3. If gateway is the bottleneck, add a verify-gate retry on `helia.pins.add` failure (similar to the at-least-once Nostr→IPFS pattern that landed for issue feat(uxf): UXF Inter-Wallet Transfer Protocol — implementation (51 of 52 plan tasks) #105).

Related

• sphere-sdk Profile/OrbitDB: invoice tokens not durable across CLI process exit — manual-test-full-recovery.sh §C.1b blocker #234 — IPFS pin propagation root cause investigation
• sphere-sdk Profile: shutdown must verify remote IPFS + aggregator durability before exit (root cause of #234 manual-test failure) #239, fix(profile)(#239): per-flush + opt-in shutdown remote-durability gate #240 — Helia v6 + FsBlockstore + per-flush+opt-in shutdown gate
• sphere-sdk Client-side Helia/libp2p bootstrap is too heavy — clients should HTTP-only to operator Kubo gateway(s) #266 — HTTP-only IPFS default
• sphere-sdk Flush-durability verify gate (#239) too aggressive on testnet — at-least-once loop in §C.2 #268 — flush-durability verify gate (TimedOut on §C.2)