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

[dborup]

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.

Site	List	Cap	Frontend
cmd/server/node_analytics_summary.go:409	peerInteractions	20 (random cut)	public/node-analytics.js:152
cmd/server/node_analytics_summary.go:391	observerCoverage	none	public/node-analytics.js:249
cmd/server/store.go:10521	observerRows (GetNodeHealth)	none	public/live.js:2694
cmd/server/store.go:10353	observerRows (GetBulkHealth)	none	same shape

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.

[dborup]

Fixed by #325 (merged as bf3151a4dc3c302c884ef922a43c4c92624fc8fc).