Bolt: HA-aware ROUTE response with multi-server routing table #5002

Part of #4890. Epic #4882.

Covers conformance scenario CONN-004 (bolt/conformance/spec.yaml), currently current_status: expected-fail (kept @Disabled/skip in the Group B suites because it needs a real cluster).

Motivation

handleRoute returns this node's own address as writer, reader and router - there is no HA-aware multi-server address list. neo4j:// routing/discovery against an ArcadeDB cluster is therefore unproven: a driver cannot discover the leader/followers or route reads vs writes correctly.

Note: this is distinct from CONN-003 (neo4j:// single-node), which passes on Linux CI and only fails on macOS/Docker Desktop due to the container bridge address not being host-routable.

Proposed design

• Populate the ROUTE response from the HA cluster's live membership: advertise the leader as the WRITE server and followers as READ servers, all as ROUTE servers, with the configured TTL.
• Map internal HA addresses to client-reachable Bolt advertised addresses (respect any advertised-address / hostname config).
• Fall back to current single-node behavior when HA is not enabled.

Acceptance criteria

• CONN-004 passes against a multi-node cluster: a neo4j:// driver discovers writer + reader(s) and routes accordingly (re-enable the disabled/skipped scenario in the suites).
• Single-node (non-HA) ROUTE behavior unchanged.
• Reader/writer classification tracks leader changes.

Dependencies

Depends on the HA/cluster layer (server.ha.*) for membership + leader identity. Requires a multi-node test harness.

Effort estimate

M