Add an official Rust API client

## Describe the problem

Algolia currently does not provide an official Rust API client.

There are community crates such as [`algoliasearch`](https://crates.io/crates/algoliasearch), but these are not officially supported and some have seen little maintenance for quite some time.

As a result, Rust users either need to depend on an unofficial client or implement the required parts of the Algolia API themselves.

I've ended up doing the latter in several projects, implementing small blocking clients using [`ureq`](https://crates.io/crates/ureq), for example:

- https://github.com/techouse/alfred-tailwindcss-docs/blob/master/src/services/algolia.rs
- https://github.com/techouse/alfred-gitmoji/blob/master/src/services/algolia.rs
- https://github.com/techouse/alfred-django-docs/blob/master/src/services/algolia.rs

While making a basic request to the Algolia API is straightforward, a robust client quickly needs to deal with details such as authentication, request and response types, host selection and failover, retries, timeouts, error handling, and API changes.

Reimplementing this across Rust projects is both laborious and error-prone.

## Describe the solution

It would be great to add Rust as an officially supported language to `api-clients-automation` and generate an official Rust client from the same OpenAPI specifications used for the existing clients.

Ideally, the generated client would:

- provide strongly typed request and response models;
- use `serde` for serialisation/deserialisation;
- implement the standard Algolia host selection, retry and failover behaviour;
- cover the same APIs and participate in the same common test suite as the other generated clients;
- be published to crates.io and maintained as part of the normal Algolia API client release process.

I don't have a strong preference as to whether the initial implementation is blocking, async, or supports both. Having an officially maintained Rust client that stays in sync with the Algolia API would already solve the main problem.

Since this repository already contains the API specifications, client generation infrastructure, common tests, and documentation for adding new languages, Rust seems like a good candidate for another generated client.

## Alternatives you've considered

The main alternatives today are:

1. **Use an existing community crate.**
This avoids writing a client from scratch, but means depending on an unofficial implementation whose maintenance and API coverage may not track Algolia.

2. **Publish another community Rust crate.**
I've considered extracting my implementations into a reusable crate, but this would effectively create yet another unofficial Algolia client that somebody needs to maintain independently.

3. **Call the REST API directly.**
This is what I currently do using `ureq`. It works well for small integrations, but results in the same transport, retry, host-selection, error-handling and model code being repeatedly implemented across projects.

An official generated client seems preferable to multiplying independent community implementations, particularly when Algolia already has the infrastructure for generating and testing API clients from a common specification.

Start by reading the existing client-generation infrastructure, OpenAPI specifications, common test suite, and documentation for adding a new language. Determine the design and integration points needed for a generated Rust client. Done means Rust is supported by the automation, the client covers the intended APIs and common tests, and its release and documentation paths are defined.

Written by the indexing model from the issue text.