[Epic] Refactor the MINIO module to use SILO by default

Goal

Make the Pigsty MINIO/MIO module provision and operate the SILO fork as its first-class implementation, with a clear migration path for existing MinIO deployments and a complete Metrics V3 observability path.

Why

The current module was designed around upstream MinIO (and later RustFS): package/runtime selection, environment rendering, service management, scrape configuration, Grafana dashboards, and alert rules all inherit that model. SILO gives us control over the server and Console, so the module should expose one coherent contract instead of accumulating one-off overrides.

Today the public configuration still has several coupled assumptions:

• the implementation is selected as minio or rustfs;
• the scrape path is the MinIO Metrics V2 cluster endpoint;
• the embedded Console is configured with a shared job="minio" selector but no per-cluster selector;
• bundled dashboards and alert rules query V2 metric names.

Changing only one layer would leave provisioning, Console widgets, dashboards, and alerts inconsistent.

Proposed direction

• Add SILO as a supported runtime and make it the default after the compatibility and upgrade path is documented and tested.
• Keep the established minio_* inventory API where practical. Treat it as the stable Pigsty module interface rather than forcing a disruptive variable rename.
• Render SILO/Console observability settings as first-class role configuration.
• Scope every time series and Console query with Pigsty identity labels, especially cls for a MinIO/SILO cluster and ins for an instance.
• Scrape Metrics V3 root metrics and configured bucket metrics with bounded, predictable cardinality.
• Port the shipped Grafana dashboards and VictoriaMetrics alert rules to V3 semantics.
• State explicitly which legacy MinIO/RustFS combinations remain supported and how operators migrate or opt out.

Child issues

• #766 — Render SILO observability configuration as first-class MINIO role settings
• #764 — Scope embedded SILO Console metrics to the current MINIO cluster
• #767 — Switch the MINIO scrape pipeline to Metrics V3 and configured bucket metrics
• #765 — Port bundled MINIO Grafana dashboards and alert rules to Metrics V3

Related Console work:

• pgsty/silo-console#7
• pgsty/silo-console#8

Compatibility decisions required

1. Whether minio_type: silo is introduced first and becomes the default in a later release, or changes in the same release.
2. Which old MinIO/RustFS versions remain provisionable and whether they keep a V2 scrape profile.
3. Package, binary, service, data-directory, CLI, and environment-file naming during upgrades.
4. Whether SILO emits compatibility aliases for any V2 metric names, or Pigsty consumers move directly to native V3 names.
5. Upgrade/rollback behavior for an existing distributed cluster; no in-place destructive action should be implicit.

Definition of done

• Fresh single-node and distributed SILO clusters provision successfully over HTTP and TLS.
• An existing supported MinIO deployment has a documented, tested migration or compatibility path.
• Re-running the role is idempotent and check mode does not report avoidable drift.
• Multiple SILO clusters can share one VictoriaMetrics tenant without Console or dashboard cross-talk.
• Root and configured-bucket V3 metrics are present with stable job, cls, and ins labels and bounded cardinality.
• Shipped dashboards render without missing-query panels and alert rules evaluate without errors.
• Operator documentation covers deployment, migration, monitoring, and rollback.

Start by reading child issues #766, #764, #767, and #765, then map the existing MINIO module's provisioning, scrape pipeline, dashboards, and alert rules. Resolve the five compatibility decisions and define tests for fresh, upgraded, idempotent, and multi-cluster deployments. Done means every Definition of done item passes and operator migration and rollback documentation is complete.