tarantool-etcd-huo etcd /metrics compatibility — match upstream Prometheus metric names + endpoint Lined Up

Expose a Prometheus /metrics endpoint whose metric names, label sets, and types match upstream etcd's, so existing etcd Grafana dashboards, recording rules, and alerts work unchanged against tarantool-etcd. This is the compatibility layer on top of the underlying metrics integration (tarantool-etcd-unw): map our collected operational stats onto etcd's canonical series — e.g. etcd_server_has_leader, etcd_server_leader_changes_seen_total, etcd_mvcc_db_total_size_in_bytes, etcd_server_proposals_committed_total, grpc_server_handled_total{grpc_method,grpc_code}, etcd_network_peer_round_trip_time_seconds, etcd_debugging_mvcc_keys_total, etc. Scope to nail down: which series are meaningful for a Tarantool backend vs which must be emitted as constants/stubs to satisfy dashboards, the /metrics text-format exposition path (does it ride the JSON gateway or a dedicated listener), and a conformance check that scrapes both real etcd and tarantool-etcd and diffs the metric name/label surface.

etcd 3.7 metric surface additions (from the 3.7.0 announcement) — fold into the name/label diff, and note that the diff must be taken against a 3.7 scrape once tarantool-etcd-cc7 bumps the conformance backend off 3.6:

- etcd_server_request_duration_seconds (new, non-debugging — likely dashboard-relevant)
- etcd_debugging_server_watch_send_loop_watch_stream_duration_seconds
- etcd_debugging_server_watch_send_loop_watch_stream_duration_per_event_seconds
- etcd_debugging_server_watch_send_loop_control_stream_duration_seconds
- etcd_debugging_server_watch_send_loop_progress_duration_seconds

The four watch send-loop series are etcd_debugging_* and describe upstream's internal watch send loop, which our watch.lua (fiber.cond + kv_history catch-up) has no structural analogue for — candidates for the 'stub or omit' bucket rather than the 'map' bucket.