Token-aware batch routing uses wrong tablet metadata lookup context

[dkropachev]

Broken behavior

Token-aware routing for BatchStatement can fail to use tablet metadata even when the batch has a valid routing key.

Reproducer

1. Create a tablet-enabled keyspace and table.
2. Learn tablet metadata for the table.
3. Execute a BatchStatement containing a bound statement with a valid routing key.
4. Observe the hosts selected by TokenAwarePolicy.

Expected:

• the batch routing key and table name are derived from the same routed child statement;
• tablet replica lookup uses that table name;
• the query plan stays within the expected tablet replicas.

Actual:

• the batch exposes a routing key, but tablet table-name extraction is done from the outer batch statement context;
• TokenAwarePolicy cannot resolve the correct tablet table for the batch;
• routing can fall back instead of using tablet metadata.

Cause

TokenAwarePolicy handled table-name extraction for direct BoundStatement and PreparedStatement inputs only. A BatchStatement needs an extra step: select the child statement that provides the routing key, then derive table metadata from that same child.

Fix

Resolve batch routing metadata through the routed child statement and keep existing direct statement behavior unchanged.

Verification

Covered by focused unit tests for TokenAwarePolicy and a CCM-backed tablet integration test using Scylla release:2026.1.

Customer Reference

• CUSTOMER-323

[Lorak-mmk]

Is it really a bug? If we define that we route batch exactly as we would route its first statement, this it seems like an expected behavior.
We do have the same behavior in Rust Driver.