[NEW] Include run_id in the HELLO reply so clients can identify the server at connect

The problem/use-case that the feature addresses

A client connecting through a proxy, load balancer, or Sentinel/HA endpoint has no cheap way to tell which server instance it's actually talking to. The connection address is the entry point, not the backend, and the HELLO reply's id field is the per-connection client id, not a server identity.

Today the only stable per-server identifier is run_id, available via INFO. But INFO is a separate round-trip, returns a large payload, and can be restricted by ACLs — so a client that just wants to know "which server am I connected to?" (for failover/reconnect detection, connection affinity, logging, diagnostics) has to make an extra call and parse INFO for one field.

Description of the feature

Include run_id in the HELLO reply map, alongside the existing server, version, proto, id, mode, role, and modules fields.

Since HELLO is already part of the RESP3 handshake, clients would get the server's identity at connect time with no extra command — and it comes from the actual backend that served the handshake, even through a transparent proxy. run_id is already computed and exposed via INFO server, so this just surfaces an existing value in the handshake.

Alternatives you've considered

• Reading run_id from INFO — works today, but it's a separate round-trip, a much larger reply, and can be blocked by ACLs when a client only needs this one field at connect.
• The HELLO id field — this is the per-connection client id (ephemeral, unique per connection), not a server identity, so it can't tell you which server you're on.
• CLIENT ID / CLIENT INFO — also per-connection, not server-level.

Additional information

run_id is stable for a server process's lifetime and changes on restart — itself a useful signal for a client detecting it has reconnected to a restarted or different instance after a failover.

This would also let client libraries and observability tooling record which server served a request without an extra INFO round-trip — for example, an OpenTelemetry instrumentation request (open-telemetry/opentelemetry-java-instrumentation#19946) currently has to fall back to calling INFO at connect for exactly this reason.

Happy to raise a PR if this seems reasonable.