Save new worker registration with its first heartbeat

[raphael]

A pool node can try to clean up a worker while another node is still creating it. The constructor previously saved the worker before its first heartbeat, so cleanup could claim the newly visible worker and make AddWorker fail. Worker registration now saves both records in one Redis operation. Repeating that operation returns the same first heartbeat, so a delayed command cannot replace the timestamp the constructor is waiting for.

The pool owns registration and cleanup. It checks that the pool, node, and original worker stream are still active before saving anything. A failed constructor destroys its stream before removing both registration records; if destruction fails or another node has claimed cleanup, it preserves the records that cleanup needs. AddWorker also checks lifecycle state without holding the local lock needed for retirement. Callers keep the same inputs and result types, including the existing lifecycle errors.

Stored record formats and public APIs are unchanged. Old and new pool nodes can share the same records, although an older node retains the original constructor race. Review pool/worker_registration.go, Node.AddWorker, and newWorker first.