Replace opaque VirtualNode with domain-typed connection addressing

[SamBarker]

Summary

Proposes a ClientAddressing sealed interface to replace the opaque VirtualNode
marker in the Router API (refining Proposal 070). The sealed hierarchy uses Kafka
domain types — Bootstrap for connections to the virtual cluster's bootstrap address,
Broker for broker-specific connections — making the distinction compiler-checkable
and self-documenting.

Also proposes:

• clientAddressed() replacing Optional<VirtualNode> virtualNode()
• sendToRoute() collapsing the anyNode() + sendRequest() two-step
• brokerFor(int) replacing nodeForId(int)
• sendRequest(Broker, ...) overload alongside deprecated sendRequest(VirtualNode, ...)

All deprecated methods receive default implementations that delegate to their
replacements — no runtime breaks during the migration window.

Context

The bootstrap/broker distinction surfaced independently from two directions:
the port-binding separation work (#4147) arrived at a sealed two-case type
from the networking layer, and review of the dynamic routing PR (#4307,
discussion)
raised the question of what state VirtualNode should expose. This proposal
addresses both by replacing VirtualNode with a domain-typed sealed hierarchy.

[SamBarker]

Is Controller as a future peer subtype well-served by the flat hierarchy, or does the two-level hierarchy (rejected here) better justify itself despite Controller being hypothetical? The motivation for Controller is the proxy standing between members of the Kafka cluster — not just between clients and brokers. The flat design doesn't foreclose the two-level option later, but reviewers with a view on whether the proxy will need to mediate controller connections may have a stronger opinion on whether that extensibility point is worth pre-building.