Add platform-specific client class for multi-platform support

Currently, the client logic handles operations in a platform-agnostic way, but we’ve already encountered cases where error handling is platform-specific (e.g., error code 16500 in Azure Cosmos DB for MongoDB indicates a RU-throttling issue, but on other platforms it has different error codes).

To make the client safer and more maintainable as we expand platform support, we should consider a refactor where the client has knowledge of the target platform. Possible directions:

• Introduce an abstract base client (BaseClient) that defines the shared interface.
• Implement platform-specific clients (GenericClient, RUClient, …) that encapsulate special cases like error handling, throttling, or query behavior.
• Refactor existing logic to delegate appropriately, reducing complexity and improving separation of concerns.

It could also be combined with the upcoming effort to simplify and modularize client logic, since the current implementation is already too complex and mixing responsibilities.

Next steps:

• Add stronger error content checks in the current implementation to make assumptions safer (short-term).
• In future, design and implement a client hierarchy that supports multiple platforms cleanly.

No implementation files or tests are named. Start by tracing the current client logic and reviewing the platform-specific error example in PR #213; completion would require an agreed client hierarchy and delegated platform-specific behavior, with the existing responsibilities separated clearly.