Let a single active node run clustered without pausing jobs or failing health checks

[binwiederhier]

Phil's Robot: Makes it safe to turn clustering on in production with the production server as the only active node and any other nodes passive (#2049): nothing changes for clients, and the cluster code can be watched under real load.

Builds on #2040 (the message cache tail) and #2049 (node roles), both merged.

Why

With clustering on, a single active node behaved worse than with clustering off, in two ways:

1. Scheduled jobs paused after every restart. Only the leader runs delayed messages and Firebase keepalives, and a node becomes leader only after a hold-off of two node TTLs (60s). With clustering off, a node is always leader.
2. /v1/health returned 503 during a database blip. It reported unhealthy whenever the registry heartbeat was stale, so a load balancer check would pull the only active node and leave its clients nowhere to go.

Changes

Lead right away when no other active node was live recently. The hold-off exists so a previous leader's belief cannot overlap with its successor's. If no other active node heartbeated within the lease plus the hold-off (90s with the default TTL), nobody can still believe it leads, so the node leads at once. Any recently live active node still means the full hold-off, so failover and a returning lower id behave as before.

Report unhealthy only when another active node can take the clients. New Cluster.Serving(): true when the registry heartbeat is fresh, or when the last peer snapshot has no active peer. /v1/health uses it. Peer probes between nodes still use Healthy().

Readiness, separate from health. A passive node is healthy, so /v1/health answers 200 for it, and a load balancer checking only that would send it clients. New /v1/ready: 200 only for an active node that is serving; 503 with {"ready":false,"role":"passive"} otherwise. /v1/health keeps its meaning and now also reports the role, so monitoring can tell a passive (or later draining) node from a broken one. Load balancers should check /v1/ready; documented in docs/config.md.

Tests

Red first, then green:

• TestRegistry_AloneLeadsRightAway, TestRegistry_OnlyPassivePeersLeadsRightAway, TestRegistry_RecentlyLiveActivePeerMeansHoldOff (the guard); TestRegistry_LowestLiveNodeLeads adjusted: the first node to register alone may lead at once, never two at a time.
• TestMesh_ServingWithoutAnActivePeer, TestMesh_NotServingWhenAnActivePeerCanTakeOver.
• TestServer_Cluster_HealthReportsRole, TestServer_Cluster_Ready, TestServer_ReadyWithoutClustering.
• TestServer_Cluster_ActiveWithPassivePeer: two full servers on one database, active and passive. The active node leads within seconds (fails without the change: the hold-off is a minute), the passive one never, each delivers the other's messages, /v1/health is 200.

go test ./..., race runs of the cluster and server packages, and make lint pass. A lab run with this setup (app1 active, app2 and app3 passive, 350 messages/s, restarts, kill -9 and a Postgres cut-off of the active node) is in progress; results follow.