What this PR does / why we need it:

The generic OnlineStore._read_features_per_fv loop reads one feature view after another. For DynamoDB that means a sync get_online_features call spanning N feature views costs at least N sequential BatchGetItem round trips, and the async path sends at least N separate requests. Redis and PostgreSQL already override this seam to batch. This PR does the same for DynamoDB, as discussed in #3259, where per-store overrides were agreed as the approach.

DynamoDB keeps each feature view in its own table, and one BatchGetItem request can read from several tables. The override:

• resolves every view's table name (versioning included) and entity ids up front;
• packs all of the keys into as few requests as possible, with at most batch_size keys per request across all of its tables. Each table keeps its own ProjectionExpression and ConsistentRead;
• sends the requests in parallel: a thread pool capped at max_read_workers on the sync path, asyncio.gather on the async path;
• splits the returned items back apart by table and entity id, and fills the response in grouped_refs order.

For example, a request for 10 feature views and 5 entities now needs 1 BatchGetItem call instead of 10.

BatchGetItem rejects a request that lists the same key twice for a table. So views that map to the same table, such as one feature view requested under two aliases, are read once, projecting the union of their requested features. Extra features in a row are already ignored when the response is filled.

The gating follows the PostgreSQL implementation (#6832):

• A single-view request always takes the generic path, because there is nothing to combine.
• Requests larger than the new max_batched_result_rows setting (entity rows × feature views, default 2048) also take the generic path. At that size each view already fills requests of its own, so packing saves at most one partly filled request per view, while holding every view's items at once raises peak memory.
• Setting max_batched_result_rows: 0 turns batching off.

Error and throttling behaviour does not change: any exception from batch_get_item still propagates, and UnprocessedKeys are handled the same way as in the per-view path. The item decoding in _process_batch_get_response moves into a shared _to_read_row helper, so both paths parse items the same way.

Docs: the DynamoDB online store reference (new option plus a performance note) and the online server performance tuning guide.

Which issue(s) this PR fixes:

Refs #3259

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests
• Manual tests
• Testing is not required for this change

New tests are in sdk/python/tests/unit/infra/online_store/test_dynamodb_batched_read.py. They run against moto-backed tables, and each one covers both the sync and the async override:

• One request serves three views (two of them share an entity id and a feature name, and the third is keyed on a different entity), and the response matches the generic per-view path exactly, including entities that are missing from one view.
• Keys are packed across tables up to batch_size.
• Aliases of one view read each key once, with the union projection.
• Projection is set per table.
• A single view, max_batched_result_rows: 0, or a request over the limit falls back to one online_read per view.
• Config default and validation.

The existing DynamoDB unit tests still pass.

Misc

Release note: The DynamoDB online store now packs the reads of every feature view in a request into shared BatchGetItem calls, so requests that span several feature views need fewer round trips. The new max_batched_result_rows option controls this.