Deterministic tie order in four more count-only sorts (node analytics, node/bulk health) #321

Follow-up to #319 (#273), from the review of #319. The same tie-order bug class as #256/#293/#273: count-only sorts over map iteration with no secondary key, so tied entries come out in a random order on each call. All of them are shown to the user.

Lower priority, same shape: cmd/server/store.go:9569 (collisions) sorts on class order, then Appearances, with no final key.

The peerInteractions cap makes the first site the most visible. With ties at the cut-off, which peers are shown changes between calls, not just their order.

Acceptance

• Each site gets a stable secondary key, the same pattern as rankSubpaths (Reapply #261: deterministic order for tied Hash Stats adopters (#256) #293) and fix(server): deterministic tie order in GetSubpathDetail (#273) #319.
• A test with tied entries that is red before the fix for each site, or a shared table test covering all of them.
• One mutant check per site.
• No perf regression: a comparator-only change.

Line numbers are from origin/master at 2820d18d and may drift.