Observe the running etcd version in EtcdMember status and key version-dependent logic off it

[androndo]

Background

Spun out of the review on #337 (per reviewer request — future work, not folded into that PR).

Today spec.version is treated as the source of truth for the running etcd version: it is injected as ETCD_VERSION, drives the restore version-compat pre-flight, the latched target, and drift detection. The member never reports what version it is actually running.

Problem

Because nothing observes the real running version, intent (spec.version) and reality can silently diverge — there is no signal to detect or reconcile a mismatch. This was the blocking reason a per-cluster image tag override (spec.image.tag) was dropped from #337: a tag resolving to a different minor than spec.version is internally contradictory and unvalidated.

Proposal

• The member determines, at runtime, the etcd version it is actually running and writes it to its status (e.g. EtcdMember.status.version, read from the etcd endpoint / /version).
• The operator's version-dependent logic keys off that observed value, not the spec field.

Why it matters

This is the principled fix for the spec-vs-reality conflict. With an observed version in status, a per-cluster image/version override (deferred in #337) could be reconsidered safely, and version drift/upgrade handling becomes detectable rather than assumed.

Refs: #337