feat: optimize seven Sealos application templates

[yangchuansheng]

Summary

• Optimize seven Sealos templates: Signoz, Harbor, Budibase, NetBird, MLflow, DataEase, and OpenList.
• Pin supported application images and preserve each template's required topology.
• Add conditional Sealos S3 and managed PostgreSQL choices where supported.
• Tune resources from live deployments and record topology/runtime evidence.
• Refresh English and Simplified Chinese READMEs with deployment options, credentials, login guidance, and resource requirements.
• Add authenticated application screenshots for all seven templates.

Fixes

• Signoz: fix ClickHouse wildcard listener configuration and tune the storage stack.
• Harbor: eliminate the Jobservice startup race and move the Trivy database cache to ephemeral storage.
• Budibase: align storage configuration with the official S3-backed deployment model.
• Budibase: add a CouchDB startup probe, single-node shard configuration, and stable Erlang node naming for the slow database bootstrap.
• Budibase: use scheme-qualified Redis URLs for Apps and Worker.
• Budibase: configure managed object-storage SNI and Host headers in the Proxy so HTTPS requests avoid TLS handshake failures and ingress recursion.
• NetBird: add the managed PostgreSQL path and tune management memory for stable startup.
• MLflow: add Basic Auth, SQLite/PostgreSQL and local/S3 artifact modes, use MLflow v3.14.0, and size the service at 2 CPU / 2 GiB from live OOM evidence.
• DataEase: correct the MariaDB JDBC URL and configure database connection capacity through KubeBlocks.
• OpenList: add conditional managed PostgreSQL and Sealos S3 storage modes.

Verification

• Strict docker-to-sealos quality gate passed: 213 self-tests, 48 consistency checks, 5 compose checks, and 58 template rules.
• Fifteen server-side dry runs across storage and database combinations returned HTTP 200 with the expected conditional resources.
• Live deployment checks covered authentication, core UI workflows, API operations, artifact/object upload and download, persistence across pod replacement, and stable log windows.
• Budibase live verification covered administrator login, Settings and Apps pages, CouchDB Dreyfus search, managed S3 upload and /files/signed/ download with SHA-256 comparison, and proxy negative-route behavior.
• Budibase stability observation kept all six related Pods Ready with zero restart delta and zero active log failures across the final window.
• All seven live test footprints were deleted, including Instance resources, clusters, PVCs, and object storage buckets.