docs: rebrand the repository documentation, templates and dashboards

README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE,
code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue
and pull request templates, and the docs/ tree all present Silo as the product.
The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel
titles and descriptions rebranded while every minio_* query, label and
expression is left alone, so existing alerts and recording rules keep matching.

The distinction the review demanded is applied per hit rather than by
search-and-replace:

- Product and command text becomes Silo and silo: install and run instructions,
  systemd examples, compose services, download links, badges.
- Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics,
  x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and
  error names.
- Attribution keeps MinIO and gains the fork's own: the AGPL obligations,
  original copyright, CREDITS and NOTICE stay, with the modification notice
  added alongside rather than replacing them.
- Historical and third-party references are left as facts, not rewritten for
  brand tidiness.

README and README_ZH each carry an explicit non-affiliation notice, document
the side-by-side package migration including the
/etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a
legacy UID/GID, and state that recursive chown is never performed. The trademark
attribution uses the policy's approved "based on MinIO technology" wording, not
the shortened form the policy rejects.

github.com/pgsty/minio links are left in place and labelled transitional. The
repository has not been renamed, and rewriting them now would produce documented
URLs that 404 until the cutover; they change in the cutover commit together with
the goreleaser release target, the OCI source label and the raw-content branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/minio-limits.md

@@ -1,6 +1,6 @@
-# MinIO Server Limits Per Tenant
+# Silo Server Limits Per Tenant
 
-For optimal production setup MinIO recommends Linux kernel version 4.x and later.
+For optimal production setup Silo recommends Linux kernel version 4.x and later.
 
 ## Erasure Code (Multiple Drives / Servers)
 
@@ -34,30 +34,33 @@ For optimal production setup MinIO recommends Linux kernel version 4.x and later
 | Maximum length for '/' separated object name segment                            | 255                                                                             |
 | Maximum number of versions per object                                           | 10000 (can be configured to higher values but we do not recommend beyond 10000) |
 
-> NOTE:  While MinIO does not implement an upper boundary on buckets, your cluster's hardware has natural limits that depend on the workload and its scaling patterns. We strongly recommend [MinIO SUBNET](https://min.io/pricing) for architecture and sizing guidance for your production use case.
+> NOTE: While Silo does not implement an upper boundary on buckets, cluster
+> hardware has natural limits that depend on workload and scaling patterns.
+> Benchmark the intended workload and size production deployments with
+> operational headroom.
 
-## List of Amazon S3 APIs not supported on MinIO
+## List of Amazon S3 APIs not supported on Silo
 
-We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/minio/issues) with relevant details on why MinIO must implement them.
+We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/minio/issues) with relevant details on why Silo must implement them.
 
-### List of Amazon S3 Bucket APIs not supported on MinIO
+### List of Amazon S3 Bucket APIs not supported on Silo
 
 - BucketACL (Use [bucket policies](https://silo.pgsty.com/administration/identity-access-management/policy-based-access-control/) instead)
 - BucketCORS (CORS enabled by default on all buckets for all HTTP verbs, you can optionally restrict the CORS domains)
 - BucketWebsite (Use [`caddy`](https://github.com/caddyserver/caddy) or [`nginx`](https://www.nginx.com/resources/wiki/))
 - BucketAnalytics, BucketMetrics, BucketLogging (Use [bucket notification](https://silo.pgsty.com/administration/monitoring/bucket-notifications/) APIs)
 
-### List of Amazon S3 Object APIs not supported on MinIO
+### List of Amazon S3 Object APIs not supported on Silo
 
 - ObjectACL (Use [bucket policies](https://silo.pgsty.com/administration/identity-access-management/policy-based-access-control/) instead)
 
-## Object name restrictions on MinIO
+## Object name restrictions on Silo
 
-- Object name restrictions on MinIO are governed by OS and filesystem limitations. For example object names that contain characters `^*|\/&";` are unsupported on Windows platform or any other file systems that do not support filenames with special characters.
+- Object name restrictions on Silo are governed by OS and filesystem limitations. For example object names that contain characters `^*|\/&";` are unsupported on Windows platform or any other file systems that do not support filenames with special characters.
 
 > **This list is non exhaustive, it depends on the operating system and filesystem under use - please consult your operating system vendor for a more comprehensive list of special characters**.
 
-MinIO recommends using Linux operating system for production workloads.
+Silo recommends using Linux operating system for production workloads.
 
 - Objects must not have conflicting objects as parent objects, applications using this behavior should change their behavior and use non-conflicting unique keys, for example situations such as following conflicting key patterns are not supported.