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

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.

Start with light-base/src/lib.rs and trace how the live peer_count is currently used, then inspect lifecycle_unstable_follow and the host handling around system_health and bootstrapComplete. Determine how a peer-count lifecycle event would reach the host without the bootstrap-time runtime-service delay; done means the count remains useful during loading without relying on the brief health response.