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 [¹](https://hub.docker.com/r/diygod/rsshub/tags) 已经按照日期发布 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

- [x] I have searched [existing issues](https://github.com/DIYgod/RSSHub/issues) to ensure this feature has not already been requested and this is not a [new RSS proposal](https://github.com/DIYgod/RSSHub/issues/new?assignees=&labels=RSS+proposal&template=rss_request_en.yml).

Start by locating the GitHub Actions workflow that builds the Docker image and review how the image's date tags are produced. Read flake.nix and pnpm-lock.yaml to understand the downstream versioning constraint. Done means a successful image build creates a matching date-based Git tag such as v2026.02.20, with the source state traceable for downstream packaging.

Written by the indexing model from the issue text.