Make LazyQueryPlan generate retry nodes on demand

Problem

LazyQueryPlan is intended to be lazy in the sense that routing should select the first node for the request, then only generate additional nodes if the SDK retries and asks for another target.

Today the implementation is only lazy until first access. ensureInitialized() snapshots and builds the full remaining plan when hasNext() or next() is first called. In seeded/key-affinity mode this can call drainSeeded(...), which computes the entire deterministic order up front even though most requests only use the first node.

Why this matters

For the common successful request path, the client should avoid doing work needed only for retries. This is especially relevant for key-affinity plans, where we only need the first active node initially; the rest of the deterministic sequence is only needed after a failure/retry.

Desired behavior

• Create the request plan in beforeExecution as today.
• On first routing attempt, compute only the first target node.
• If that attempt fails and the SDK retries, compute the next target then.
• Keep existing no-duplicate behavior across retries.
• Keep seeded/key-affinity ordering compatible with the existing Go-compatible GoRand pick-and-remove sequence.
• Preserve the current key-affinity behavior where the deterministic ring is based on all discovered scoped nodes and inactive nodes are skipped.

Notes

This likely means LazyQueryPlan should keep a mutable candidate set and a PRNG/cursor, but not materialize the full ordered retry list in ensureInitialized(). hasNext() may need at most a one-node lookahead because the AWS SDK calls it before next(), but it should not drain the full plan.

Start by tracing LazyQueryPlan through beforeExecution(), ensureInitialized(), hasNext(), next(), and drainSeeded(...), then inspect how GoRand selects scoped active nodes. The change is complete when the first target is computed alone, retries generate one subsequent target at a time, no duplicates remain, and seeded/key-affinity ordering stays compatible.