The peer count is only visible for ~100ms because system_health does not answer during bootstrap

[BigTava]

Measured over five cold smoldot-direct runs: the peer count under the loading headline is visible for a median of 100ms per load (min 75ms, max 101ms), and only ever reads "2 peers".

The cause is the data source, not the wiring. system_health awaits is_near_head_of_chain_heuristic() inside smoldot, which round-trips to a runtime-service task that is busy while the chain is warping. So the first health reply lands just before bootstrapComplete, and the host clears the detail line on bootstrapComplete because a peer count is meaningless once the chain is ready. The result is a readout that is correct and almost never seen.

Options, roughly in order of value:

1. Upstream a peer-count lifecycle event. Smoldot's watchdog already keeps a live peer_count in light-base/src/lib.rs and only uses it for the 30s NoPeers threshold. Emitting it through lifecycle_unstable_follow is about ten lines and needs no polling at all.
2. Keep showing the count after bootstrapComplete while later phases run. Cheap, but it means displaying a number that no longer describes what the user is waiting for.
3. Accept it. The stall copy ("searching for peers") is the part that earns its place on a genuinely slow connection, and that path is unaffected.

My recommendation is 1, with 3 in the meantime. Worth noting that the same five runs show chain sync taking only 1.4s of a 14.8s load, while the bitswap content fetch takes 12.4s, so peer counts are not where the waiting actually happens.

[BigTava]

Substantially improved on the PR branch, though the underlying system_health limitation stands.

Root cause of the invisibility turned out to be two things, not one. The first is the one described above: system_health does not answer promptly while a chain bootstraps, so the Asset Hub's count lands about a hundred milliseconds before bootstrapComplete clears it. The second was a plain bug. The protocol client kept a hand-written runtime list of valid milestone kinds guarded by satisfies ChainSyncKind[], which only proves the entries present are valid and says nothing about the ones missing. Three kinds added to the resolver were dropped in silence at the boundary. That list is now a Record<ChainSyncKind, true>, so an omission fails typecheck, and a test iterates the exported vocabulary.

With both fixed, the step narrates itself from signals that do arrive on time. The relay reports a peer count roughly a second before the Asset Hub does, and warpSyncFinished fills what used to be a silent second between the relay finishing and the Asset Hub finding its first peer.

Measured over five cold smoldot-direct runs, the detail line under the headline is now filled for a median of 1501ms of the 1553ms step, which is 97 percent of it, against about 100ms and 6 percent before. The sequence is "connecting to peers" for 585ms, then the relay's "1 peer", then "relay ready, reaching Asset Hub" for 863ms, then the Asset Hub's "2 peers" at the handover.

Keeping this open for the upstream item, since that is still the right fix. Smoldot already tracks a live peer count in its watchdog and only uses it for the NoPeers threshold, so emitting it through lifecycle_unstable_follow would give a count that is correct throughout the step rather than one assembled from two chains.