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>

PULL_REQUESTS_ETIQUETTE.md

@@ -1,12 +1,12 @@
-# MinIO Pull Request Guidelines
+# Silo Pull Request Guidelines
 
-These guidelines ensure high-quality commits in MinIO’s GitHub repositories, maintaining 
-a clear, valuable commit history for our open-source projects. They apply to all contributors, 
+These guidelines ensure high-quality commits in Silo's GitHub repositories, maintaining
+a clear, valuable commit history for our open-source projects. They apply to all contributors,
 fostering efficient reviews and robust code.
 
 ## Why Pull Requests?
 
-Pull Requests (PRs) drive quality in MinIO’s codebase by:
+Pull Requests (PRs) drive quality in Silo's codebase by:
 - Enabling peer review without pair programming.
 - Documenting changes for future reference.
 - Ensuring commits tell a clear story of development.
@@ -15,12 +15,12 @@ Pull Requests (PRs) drive quality in MinIO’s codebase by:
 
 ## Crafting a Quality PR
 
-A strong MinIO PR:
+A strong Silo PR:
 - Delivers a complete, valuable change (feature, bug fix, or improvement).
 - Has a concise title (e.g., `[S3] Fix bucket policy parsing #1234`) and a summary with context, referencing issues (e.g., `#1234`).
 - Contains well-written, logical commits explaining *why* changes were made (e.g., “Add S3 bucket tagging support so that users can organize resources efficiently”).
 - Is small, focused, and easy to review—ideally one commit, unless multiple commits better narrate complex work.
-- Adheres to MinIO’s coding standards (e.g., Go style, error handling, testing).
+- Adheres to Silo's coding standards (e.g., Go style, error handling, testing).
 
 PRs must flow smoothly through review to reach production. Large PRs should be split into smaller, manageable ones.
 
@@ -48,14 +48,14 @@ PRs must flow smoothly through review to reach production. Large PRs should be s
 
 ## Reviewing PRs
 
-Reviewers ensure MinIO’s commit history remains a clear, reliable record. Responsibilities include:
+Reviewers ensure Silo's commit history remains a clear, reliable record. Responsibilities include:
 
 1. **Commit Quality**:
    - Verify each commit explains *why* the change was made (e.g., “So that…”).
    - Request rebasing if commits are unclear, redundant, or lack context (e.g., “Please squash typo fixes into the parent commit”).
 
 2. **Code Quality**:
-   - Check adherence to MinIO’s Go standards (e.g., error handling, documentation).
+   - Check adherence to Silo's Go standards (e.g., error handling, documentation).
    - Ensure tests cover new code and pass CI.
    - Flag bugs or critical issues for immediate fixes; suggest non-blocking improvements as follow-up issues.
 
@@ -65,7 +65,7 @@ Reviewers ensure MinIO’s commit history remains a clear, reliable record. Resp
    - If unable to complete the review, tag another reviewer (e.g., `@username please take over`).
 
 4. **Shared Responsibility**:
-   - All MinIO contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
+   - All Silo contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
    - Multiple reviewers are encouraged for complex PRs.
 
 5. **No Self-Edits**:
@@ -80,14 +80,14 @@ Reviewers ensure MinIO’s commit history remains a clear, reliable record. Resp
 
 - **Small PRs**: Easier to review, faster to merge. Split large changes logically.
 - **Clear Commits**: Use `git rebase -i` to refine history before submitting.
-- **Engage Early**: Discuss complex changes in issues or Slack (https://slack.min.io) before coding.
+- **Engage Early**: Discuss complex changes in a GitHub issue before coding.
 - **Be Responsive**: Address reviewer feedback promptly to keep PRs moving.
 - **Learn from Reviews**: Use feedback to improve future contributions.
 
 ## Resources
 
-- [MinIO Coding Standards](https://github.com/minio/minio/blob/master/CONTRIBUTING.md)
+- [Silo Contribution Guide](CONTRIBUTING.md)
 - [Effective Commit Messages](https://mislav.net/2014/02/hidden-documentation/)
 - [GitHub PR Tips](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
 
-By following these guidelines, we ensure MinIO’s codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!
+By following these guidelines, we ensure Silo's codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!