[FEATURE REQUEST] Expose read consistency in DaprClient.get_state

## Describe the feature

Please expose an optional read-consistency argument on both synchronous and asynchronous `DaprClient.get_state()`, preserving existing defaults and positional arguments.

I encountered this while investigating `DaprSession` in the OpenAI Agents SDK. Selecting strong consistency passes `state_metadata={"consistency": "strong"}` to the Dapr client, but that only populates request metadata. It does not set the dedicated `GetStateRequest.consistency` field.

### Current behavior

With `dapr==1.16.0`, both public methods have the arguments `store_name`, `key`, `state_metadata`, and `metadata` (gRPC call metadata). The same limitation remains in the inspected current source at `e4ad1818079c5089814e4d1610b585286d28b98f`:

- [Synchronous request construction](https://github.com/dapr/python-sdk/blob/e4ad1818079c5089814e4d1610b585286d28b98f/dapr/clients/grpc/client.py#L703)
- [Asynchronous request construction](https://github.com/dapr/python-sdk/blob/e4ad1818079c5089814e4d1610b585286d28b98f/dapr/aio/clients/grpc/client.py#L641)

Both construct the request as:

```python
req = api_v1.GetStateRequest(store_name=store_name, key=key, metadata=state_metadata)
```

### Reproduction evidence

Using the installed asynchronous Dapr client and a local `grpc.aio` capture server implementing `DaprServicer.GetState` and `SaveState`, I exercised public `DaprSession.get_items()` and `add_items()` with `consistency=DAPR_CONSISTENCY_STRONG`. The client HTTP readiness check was disabled only for this isolated mock-server test; protobuf serialization and gRPC transport used the actual Dapr client.

The captured read request was:

```json
{
"store_name": "statestore",
"key": "session-strong:messages",
"consistency_enum_value": 0,
"consistency_name": "CONSISTENCY_UNSPECIFIED",
"metadata": {"consistency": "strong"}
}
```

The corresponding write request correctly carried `options.consistency = CONSISTENCY_STRONG`. This establishes the request-encoding difference; it does not demonstrate stale reads against a real state store. The wire capture exercised the async path; the sync-path observation is from source inspection.

### Expected behavior and scope

Allow callers to request `Consistency.strong` or `Consistency.eventual` through the public `get_state()` API and serialize that choice into the dedicated protobuf field. Omitting the new argument should preserve `CONSISTENCY_UNSPECIFIED`. Actual guarantees remain dependent on state-store support.

This request is limited to `get_state()`: the inspected `GetBulkStateRequest` does not have a corresponding consistency field.

## Release Note

RELEASE NOTE: **ADD** Optional read-consistency selection for synchronous and asynchronous `DaprClient.get_state()`.

Start with synchronous request construction in dapr/clients/grpc/client.py around line 703 and the asynchronous path in dapr/aio/clients/grpc/client.py around line 641. Compare the GetStateRequest fields with the existing state-consistency handling, then verify both public get_state() paths preserve existing defaults and encode the selected consistency in the dedicated protobuf field.

Written by the indexing model from the issue text.