feat(kv-router): replicate session bindings with one schema and one applier

[ishandhanani]

Summary

Fifth PR of the session-affinity unification stack (base: idhanani/session-affinity-unification-p4). Replicated session bindings get one wire schema and one applier, carried by both existing transports, with a one-release dual-publish window.

Before. Two formats and two appliers: the selection service's AffinityBindingEvent on its ZMQ mesh (with the partition; writer = random process id; applied if the worker is in the partition's catalog) and the frontend's SessionAffinityUpdate on the runtime event plane (no partition; writer = discovery instance id; applied if the worker is discovered). They could not interoperate, and the frontend payload could not scope a binding to a partition (a latent bug for multi-partition frontends).

After

lib/kv-router/src/services/selection/affinity/replication.rs:

• AffinityBindingEvent: the one schema (partition flattened as model_name and routing_group, session_id, worker_id, dp_rank, sequence, writer_id).
• AffinityEventSink: the one table sink, building the event for its partition and handing it to the host's transport closure.
• AffinityResolver::apply_replica_event(partition, event): the one applier. Skips the replica's own writer id, skips other partitions, advances the replica clock, and applies the binding only if the host can schedule its worker (TargetLiveness). Returns a ReplicaEventDisposition.
• One writer-id rule: the id installed with the table's replication sink. Frontends use their discovery instance id (stable per instance); the standalone service keeps a random non-zero process id, since it has no discovery.

Transports (unchanged in shape, one schema each):

Transport	v2	v1 (one release)
Selection service ZMQ mesh	topic dynamo.session-affinity.v2	topic dynamo.session-affinity.v1, same payload
Frontend runtime event plane	subject session_affinity_events_v2, payload AffinityBindingEvent	subject session_affinity_events, payload SessionAffinityUpdate (no partition); a receiver attributes it to its own partition, as every v1.6 frontend did

Both transports publish and apply both versions for one release so mixed-version replicas converge; applying the same binding twice is idempotent (the second apply refreshes the same version). Both v1 forms carry a TODO(v1.8) removal note. The frontend's HostAffinity records its partition for this: the embedded partition's key for KV routing, the default key for the builtin modes.

Behavior changes

Decisions with defaults needing sign-off:

1. Dual publish on both transports for one release. This doubles affinity replication traffic (one event per binding change and per lease release) on the mesh and the event plane for that release. Alternative: publish v2 only and subscribe to both, which leaves older replicas blind to newer replicas' bindings during a rolling upgrade. I chose convergence over bandwidth; flagging it.
2. Apply-time liveness is TargetLiveness. The selection service previously applied a binding if the worker was in the partition's catalog in any lifecycle state; it now requires the worker to be schedulable. The frontend KV host previously required the worker to be discovered; it now also requires the bound rank to be within the worker's known DP range (when configs are known). Both are stricter and only drop bindings the resolver would have dropped at the next request anyway.
3. Partition scoping on the frontend. A v2 event for another partition is ignored; v1 events keep today's behavior (applied to the receiving partition).

Validation

Run with RUSTC_WRAPPER= and a per-worktree CARGO_TARGET_DIR.

Command	Result
cargo test -p dynamo-kv-router --features standalone-selection --lib	1290 passed, 2 ignored (+3 replication tests)
cargo test -p dynamo-llm --lib kv_router	412 passed
cargo test -p dynamo-llm --lib session_affinity	50 passed (+1 dual-apply test)
cargo test -p dynamo-custom-policy-builtin -p dynamo-mocker	passed
cargo test -p dynamo-ext-proc	passed
cargo clippy -p dynamo-kv-router --features standalone-selection,bench --all-targets -- -D warnings	clean
cargo clippy -p dynamo-llm -p dynamo-ext-proc -p dynamo-custom-policy-builtin -p dynamo-mocker --all-targets -- -D warnings	clean
cargo fmt --all -- --check	clean

New tests: schema_round_trips_with_the_partition_flattened (JSON and msgpack), applier_scopes_by_partition_writer_and_liveness, replicas_converge_through_the_shared_schema (two resolvers with their own liveness sources, standing in for a frontend and a selection-service replica, agree on a binding through the shared schema in both directions, including a re-bind after the worker departs), and on the frontend v1_and_v2_updates_both_apply_to_the_partition (v1 converted and v2 both applied, another partition ignored, duplicate apply idempotent, applier stops when the resolver is gone). rejected_worker_update_still_advances_replica_clock and replica_update_backpressure_is_nonfatal are kept over the shared types.

Not run: cross-process replication over a real ZMQ mesh or event plane (no multi-replica fixture in the unit suites); the convergence test is at the schema and applier level.

Related Issues

• Stack: PRs 1 to 4. Upstream context: fix(kv-router): keep custom selection policies on hard session bindings ai-dynamo/dynamo#15661, feat(router): configure two-tier soft affinity ai-dynamo/dynamo#15139.
• Linear ticket: to be added (please supply the ID).