Feature Request: Adopt Calendar Versioning for Tags/Releases

What feature is it?

采用基于日期的版本号发布 GitHub Release
Adopt CalVer for GitHub Releases

建议在每次 Docker 镜像构建成功后，通过 GitHub Action 自动创建一个对应日期的 Git Tag（例如 v2026.02.20）。
We suggest using GitHub Actions to automatically create a date-based Git Tag (e.g., v2026.02.20) whenever a Docker image is successfully built.

What problem does this feature solve?

目前 RSSHub 采用滚动更新模式，虽然非常灵活，但给下游软件包（Downstream Packaging）的维护带来了巨大挑战。
Currently, RSSHub follows a rolling release model. While flexible, it creates significant challenges for downstream package maintenance.

1. Docker 与 GitHub 仓库不一致 (Inconsistency between Docker and GitHub)
   目前 RSSHub Docker Hub 1 已经按照日期发布 Tags，但 GitHub 仓库本身并没有对应的 Git Tags。这导致用户很难溯源某个 Docker 镜像对应的具体源码状态。
   Docker images are already tagged by date, but the GitHub repository lacks corresponding Git Tags. This makes it difficult to trace a specific Docker image back to its exact source code state.

2. Nix 与 AUR 构建频繁失效 (Broken Nix and AUR builds)
   在 Nix 生态中，flake.nix 依赖 pnpmDeps 的固定哈希（fixed-output hash）。由于项目频繁更新 pnpm-lock.yaml 却不同步更新 flake.nix 中的 sha256，导致 Nix 构建几乎一直处于不可用状态。
   In the Nix ecosystem, flake.nix relies on a fixed-output hash for pnpmDeps. Because pnpm-lock.yaml is updated frequently without updating the sha256 in flake.nix, the Nix build is almost constantly broken.

3. 定义与实现脱节 (Mismatch between definition and implementation) 现在的 Nix 和 AUR 软件包定义无法与项目的具体实现版本一一对应。缺乏稳定的 Release 锚点，维护者只能被迫指向 master 分支，这完全违背了可重现构建（Reproducible Builds）的原则。
   Current package definitions for Nix and AUR cannot map to a specific implementation. Without stable release anchors, maintainers are forced to track the master branch, which violates the principles of Reproducible Builds.

Additional description

No response

This is not a duplicated feature request or new RSS proposal

• I have searched existing issues to ensure this feature has not already been requested and this is not a new RSS proposal.