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/tls/kubernetes/README.md

@@ -1,16 +1,16 @@
-# How to secure access to MinIO on Kubernetes with TLS [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# How to secure access to Silo on Kubernetes with TLS
 
-This document explains how to configure MinIO server with TLS certificates on Kubernetes.
+This document explains how to configure Silo server with TLS certificates on Kubernetes.
 
 ## 1. Prerequisites
 
-- Familiarity with [MinIO deployment process on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
+- Familiarity with [Silo deployment process on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
 
 - Kubernetes cluster with `kubectl` configured.
 
 - Acquire TLS certificates, either from a CA or [create self-signed certificates](https://silo.pgsty.com/operations/network-encryption/).
 
-For a [distributed MinIO setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
+For a [distributed Silo setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
 
 For testing purposes, here is [how to create self-signed certificates](https://github.com/pgsty/minio/tree/master/docs/tls#3-generate-self-signed-certificates).
 
@@ -60,12 +60,12 @@ Note that the `secretName` should be same as the secret name created in previous
 ```yaml
     volumeMounts:
         - name: secret-volume
-          mountPath: /<user-running-minio>/.minio/certs
+          mountPath: /<user-running-silo>/.silo/certs
 ```
 
 Here the name of `volumeMount` should match the name of `volume` created previously. Also `mountPath` must be set to the path of
-the MinIO server's config sub-directory that is used to store certificates. By default, the location is
-`/<user-running-minio>/.minio/certs`.
+the Silo server's config sub-directory that is used to store certificates. By default, the location is
+`/<user-running-silo>/.silo/certs`.
 
-*Tip*: In a standard Kubernetes configuration, this will be `/root/.minio/certs`. Kubernetes will mount the secrets volume read-only,
-so avoid setting `mountPath` to a path that MinIO server expects to write to.
+*Tip*: In a standard Kubernetes configuration, this will be `/root/.silo/certs`. Kubernetes will mount the secrets volume read-only,
+so avoid setting `mountPath` to a path that Silo server expects to write to.