docs: document S3_ADDRESS_STYLE variable and add Tigris example

[davidmyriel]

Summary

• Document the S3_ADDRESS_STYLE environment variable in the S3 storage section. This variable is supported in code (api/configs/middleware/storage/amazon_s3_storage_config.py, line 37) but was missing from the docs. It controls whether boto3 uses path-style or virtual-hosted-style S3 requests.
• Add a Tigris configuration example showing how to use Tigris as an S3-compatible storage backend with the existing s3 storage type.

Changes

• en/self-host/configuration/environments.mdx: Added S3_ADDRESS_STYLE row to the S3 variable table. Added Tigris to the S3_ENDPOINT description alongside MinIO. Added a short Tigris example block with env var values.

Notes

• No new storage type — Tigris uses the existing s3 backend.
• All variable names and defaults verified against api/configs/middleware/storage/amazon_s3_storage_config.py and api/extensions/storage/aws_s3_storage.py.
• English docs only; translations sync automatically per repo conventions.

[RiskeyL]

Hi @davidmyriel, thanks for this PR! Documenting S3_ADDRESS_STYLE fills a real gap. We've also coordinated with the dev team to get it added to .env.example and docker-compose.yaml (langgenius/dify#34826), so it's now fully discoverable for self-hosted users.

We made a few adjustments to align with our documentation standards:

Kept:

• The S3_ADDRESS_STYLE row in the table — this is the core value of the PR.

Changed:

• Rewrote the S3_ADDRESS_STYLE description to explain what path and virtual actually mean (bucket name in the URL path vs as a subdomain), and added a note that it only applies when S3_USE_AWS_MANAGED_IAM is false.
• Reverted S3_ENDPOINT and S3_REGION to their original descriptions — our env var reference keeps rows provider-neutral so the table stays clean as more S3-compatible services are added.

Removed:

• The Tigris example block. Our env var docs describe what each variable does and what values it accepts — that's enough for users to configure any S3-compatible service. Provider-specific setup guides are better maintained by the respective provider communities, where they can stay up to date as those services evolve.

Appreciate the contribution!