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/site-replication/README.md

@@ -1,6 +1,6 @@
 # Automatic Site Replication
 
-This feature allows multiple independent MinIO sites (or clusters) that are using the same external IDentity Provider (IDP) to be configured as replicas. In this situation the set of replica sites are referred to as peer sites or just sites. When site-replication is enabled on a set of sites, the following changes are replicated to all other sites:
+This feature allows multiple independent Silo sites (or clusters) that are using the same external IDentity Provider (IDP) to be configured as replicas. In this situation the set of replica sites are referred to as peer sites or just sites. When site-replication is enabled on a set of sites, the following changes are replicated to all other sites:
 
 - Creation and deletion of buckets and objects
 - Creation and deletion of all IAM users, groups, policies and their mappings to users or groups
@@ -25,36 +25,36 @@ The following Bucket features will **not be replicated**, is designed to differ
 
 - **Removing a site** is not allowed from a set of replicated sites once configured.
 - All sites must be using the **same** external IDP(s) if any.
-- For [SSE-S3 or SSE-KMS encryption via KMS](https://silo.pgsty.com/operations/server-side-encryption/ "MinIO KMS Guide"), all sites **must**  have access to a central KMS deployment. This can be achieved via a central KES server or multiple KES servers (say one per site) connected via a central KMS (Vault) server.
+- For [SSE-S3 or SSE-KMS encryption via KMS](https://silo.pgsty.com/operations/server-side-encryption/ "Silo KMS Guide"), all sites **must**  have access to a central KMS deployment. This can be achieved via a central KES server or multiple KES servers (say one per site) connected via a central KMS (Vault) server.
 
 ## Configuring Site Replication
 
-- Configure an alias in `mc` for each of the sites. For example if you have three MinIO sites, you may run:
+- Configure an alias in `mc` for each of the sites. For example if you have three Silo sites, you may run:
 
 ```sh
-mc alias set minio1 https://minio1.example.com:9000 adminuser adminpassword
-mc alias set minio2 https://minio2.example.com:9000 adminuser adminpassword
-mc alias set minio3 https://minio3.example.com:9000 adminuser adminpassword
+mc alias set silo1 https://silo1.example.com:9000 adminuser adminpassword
+mc alias set silo2 https://silo2.example.com:9000 adminuser adminpassword
+mc alias set silo3 https://silo3.example.com:9000 adminuser adminpassword
 ```
 
 or
 
 ```sh
-export MC_HOST_minio1=https://adminuser:adminpassword@minio1.example.com
-export MC_HOST_minio2=https://adminuser:adminpassword@minio2.example.com
-export MC_HOST_minio3=https://adminuser:adminpassword@minio3.example.com
+export MC_HOST_silo1=https://adminuser:adminpassword@silo1.example.com
+export MC_HOST_silo2=https://adminuser:adminpassword@silo2.example.com
+export MC_HOST_silo3=https://adminuser:adminpassword@silo3.example.com
 ```
 
 - Add site replication configuration with:
 
 ```sh
-mc admin replicate add minio1 minio2 minio3
+mc admin replicate add silo1 silo2 silo3
 ```
 
 - Once the above command returns success, you may query site replication configuration with:
 
 ```sh
-mc admin replicate info minio1
+mc admin replicate info silo1
 ```
 
 ** Note **

docs/site-replication/gen-oidc-sts-cred.go

@@ -21,7 +21,7 @@
 package main
 
 // This programs mocks user interaction against Dex IDP and generates STS
-// credentials. It is for MinIO testing purposes only.
+// credentials. It is for Silo testing purposes only.
 //
 // Run like:
 //
@@ -43,7 +43,7 @@ func main() {
 
 	endpoint := os.Getenv("MINIO_ENDPOINT")
 	if endpoint == "" {
-		log.Fatalf("Please specify a MinIO server endpoint environment variable like:\n\n\texport MINIO_ENDPOINT=http://localhost:9000")
+		log.Fatalf("Please specify a Silo server endpoint environment variable like:\n\n\texport MINIO_ENDPOINT=http://localhost:9000")
 	}
 
 	appParams := cmd.OpenIDClientAppParams{