Feature Request: Route objects to different storage backends based on S3 Region

Is your feature request related to a problem? Please describe. I want to deploy a single RustFS gateway that serves S3 clients globally, but physically store data in different regions/countries based on the S3 Region specified by the client. For example:

• eu region -> store objects on a backend located in Germany
• us region -> store objects on a backend located in the USA
• jp region -> store objects on a backend located in Japan

Currently, RUSTFS_REGION only sets the global S3 Region for the whole instance (used for SigV4 signing and S3 protocol compatibility). There is no way to configure multiple storage backends and route requests to a specific backend based on the request's Region.

Describe the solution you'd like I would like RustFS to support a "bucket/object region -> storage backend" mapping, similar to a multi-region gateway or federation layer. For example, a configuration like:

region_backends:
  eu:
    endpoint: https://rustfs-germany.example.com
  us:
    endpoint: https://rustfs-usa.example.com
  cn:
    endpoint: https://rustfs-china.example.com

Or, alternatively, RustFS could support multiple "storage pools" internally, where each pool is associated with one or more S3 Regions, and a bucket created with a specific Region is pinned to the corresponding pool/backend for all subsequent operations (PUT/GET/DELETE/List/Multipart).

Ideally this should work with any S3-compatible backend (RustFS, MinIO, Ceph RGW, AWS S3, etc.) behind a single unified S3 endpoint.

Describe alternatives you've considered

1. Deploying multiple independent RustFS clusters and routing traffic at the DNS / Nginx / Envoy / S3-gateway layer. This works but adds operational complexity (credential management, bucket-to-region mapping, cross-region replication, failure handling must all be managed externally).
2. Using existing Bucket Replication / Site Replication to sync data across regions. This handles data redundancy but is not a transparent request-routing mechanism — it does not decide where an object is stored based on the request's Region at write time.
3. Using RUSTFS_REGION with multiple instances behind different endpoints. This requires clients to know and use the correct endpoint per region, which defeats the purpose of a unified regional API.

Additional context

• This is a common pattern in multi-tenant / global object storage gateways, where the client's Region (from SigV4 credential scope, or a bucket-region attribute) determines data residency and physical storage location.
• Data residency/compliance (e.g. GDPR in EU, data sovereignty in China) is the main use case.
• If this is not on the roadmap, documentation about the recommended way to build a region-aware multi-backend gateway with RustFS would also be very helpful.
• Related discussions: #1153 (global region config), #1022 (cold-file tiering to cheaper backends).