perf(bigtable): resolve O(n^2) performance bottleneck in ReadRowsQuery.add_range

[sahananshylaja-glitch]

Fixes O(n^2) performance bottleneck in ReadRowsQuery.add_range.
Linking b/573522284

Previously, add_range checked for duplicate ranges by calling self.row_ranges, which dynamically reconstructed Python RowRange wrappers for the entire query on every insert. This caused severe quadratic CPU scaling (e.g., 8,000 ranges took ~400s).

This CL optimizes the deduplication by maintaining a Python set of string signatures for O(1) lookups. This restores performant insertion (~0.14s for 8k ranges) while perfectly preserving the deduplication behavior expected by the shard() method.

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #18196 🦕

[gemini-code-assist]

Code Review

This pull request optimizes the add_range method in read_rows_query.py by introducing a set of signatures (_range_signatures) to avoid O(n^2) wrapper reconstruction during deduplication. The reviewer suggested a more efficient implementation that uses the serialized byte representation (SerializeToString()) of the underlying protobuf messages as signatures, which avoids string formatting and accessing private attributes like _pb.

[sahananshylaja-glitch]

Closing in favor of PR #18706 authored by the core maintainers based on offline feedback. Thank you