Lettuce/Jedis: record the Redis server's run_id as a span attribute

Is your feature request related to a problem? Please describe.

Today a Redis client span records the address I connected to — but not which Redis server actually answered. Those are often not the same server:

• In a replicated or clustered setup, I connect to one endpoint but different nodes may serve different requests.
• With Sentinel/HA (or any stable connection endpoint in front), the address I dial is the entry point, not the specific server behind it.
• After a restart or failover, I may be talking to a different server process than before — with nothing in the span to show it.

For diagnostics I often need to know which specific server handled a request — for example to line a slow call up with that server's own metrics, or to notice that a failover happened. Redis already has a stable per-process identifier — run_id (from INFO) — that would answer this, but the client instrumentation doesn't record it, so the span carries no server identity beyond the dialed address.

Describe the solution you'd like

Record the server's run_id as a span attribute on Redis client spans (Lettuce/Jedis) — e.g. db.redis.server.run_id (aligned with whatever the semantic conventions settle on).

Since Redis doesn't return run_id in the connection handshake (HELLO only returns server, version, proto, id, mode, role, modules), the instrumentation would read it with a single INFO server call when a connection is first opened and cache it for the life of that connection — one lightweight call at connect time, never per command.

Happy to raise a PR for this — feedback welcome on the attribute naming and the details.

Describe alternatives you've considered

• Read it from HELLO instead of INFO — passive (no extra command), but run_id isn't in the HELLO reply today, so it'd need a Redis-side change first.
• Rely on server.address — what's captured now, but it identifies the endpoint I dialed, not the server that answered.
• For reference, the Kafka instrumentation records messaging.kafka.cluster.id — a server-provided identifier independent of broker addresses — for a similar diagnostic purpose.

Additional context

This isn't about routing — the HA/endpoint setup still does its job; it's about being able to attribute a request to the server that served it, much like an X-Served-By header does for HTTP behind a load balancer. INFO server is cheap (it doesn't grow with keys or connections), and run_id is constant for a server process's lifetime — it changes only on restart, which is itself a useful signal.

Start by locating the Lettuce and Jedis instrumentation entry points and their connection-open handling; inspect how Redis client spans are created and how connection metadata is cached. Confirm the semantic attribute name, issue one INFO server lookup per connection, and cover both integrations with instrumentation tests. Done means the run_id appears on Redis client spans without a lookup per command.