feat: 全自动软件分发矩阵与一键安装脚本

[pionxe]

目的 / Purpose

响应代码审查（CR）建议，本项目需要更原生、更极客的安装体验。本 PR 构建了一套完整的全自动软件分发矩阵，包含系统级原生包管理器（Homebrew/Scoop/Debian）以及规范化至 scripts/ 目录的一键安装脚本。

变更内容 / Changes

• 📦 系统级包管理器接入:
  • brews: 自动生成 macOS/Linux 的 Homebrew Formula。
  • scoops: 自动生成 Windows 的 Scoop Manifest。
  • nfpms: 直接将 Linux 产物打包为标准的 .deb 安装包。
• 🔑 CI/CD 鉴权流: 在 release.yml 中新增 TAP_GITHUB_TOKEN 的环境变量注入，用于支持跨仓库推送（Cross-Repo Push）。
• 🚀 兜底脚本规范化: 提供 scripts/install.sh 与 scripts/install.ps1，并新增 .gitattributes 锁定 LF 换行符。

⚠️ 维护者操作指南 (Maintainer Action Required) - [BLOCKER]

非常重要：在合并此 PR 并在主干打 Tag 发版前，请管理员务必完成以下基础设施配置，否则 CI 将会因为权限不足或找不到目标仓库而报错：

1. 新建分发仓库：请在 1024XEngineer 组织下，新建两个公开的空仓库：
   • homebrew-neocode
   • scoop-bucket
2. 配置跨仓库推送令牌：
   • 请管理员使用组织账号生成一个具有 repo 权限的 Classic PAT (Personal Access Token)。
   • 前往本仓库的 Settings -> Secrets and variables -> Actions。
   • 新增一个名为 TAP_GITHUB_TOKEN 的 Secret，并将生成的 PAT 填入。

测试说明 / How to Test

所有自动化逻辑均已在我的个人 Fork 仓库中完成真实发版测试。

• GoReleaser 成功向第三方空仓库推送了 Ruby 配方与 JSON 清单。
• Release 页面成功挂载了 .deb 产物。
• scripts/ 下的脚本可正常完成下载与环境变量部署。

---

我仅在Windows平台下进行了测试使用：

Closes #80

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[minorcell]

@pionxe

1. 这个额外新建两个仓库的做法是标准做法吗 ？

[pionxe]

@pionxe

1. 这个额外新建两个仓库的做法是标准做法吗 ？

我通过查阅，普遍是提供安装脚本的。
要实现独立分发的包管理，scoop和Homebrew是这样的做法。
winget是需要我们将软件清单推至微软官方的winget-pks仓库等待审核。apt-get也是要推至官方库审核才行。
这两个仓库，只需要进行创建 一次即可，脚本会自动创建，而用户就需要订阅bucket，就可以通过命令进行一键安装。（没有scoop或Homebrew的，还是要脚本安装）

[minorcell]

@pionxe
我通过查阅，普遍是提供安装脚本的。 要实现独立分发的包管理，scoop和Homebrew是这样的做法。 winget是需要我们将软件清单推至微软官方的winget-pks仓库等待审核。apt-get也是要推至官方库审核才行。 这两个仓库，只需要进行创建 一次即可，脚本会自动创建，而用户就需要订阅bucket，就可以通过命令进行一键安装。（没有scoop或Homebrew的，还是要脚本安装）

• “提供安装脚本” 这个安装脚本是必须新仓库吗？能否是本仓库或者本仓库的某个分支

[minorcell]

@pionxe
这里至少要先回答两个问题：

1. Homebrew / Winget 是否真的必须单独仓库？
   这不是小改动，而是额外的基础设施和维护成本。如果这是生态要求，需要明确说明依据；如果不是，就要说明为什么值得引入这套复杂度。

2. 不走这套方案时，统一提供安装脚本是否可行？

   例如直接提供 curl xxx | bash，由脚本完成平台判断、下载 release 产物、安装和注册。这样用户不需要关心平台和工具，入口也更统一。这条路的关键不在“能不能做”，而在于脚本放在哪里：当前仓库、专用分支、GitHub Pages、CDN，都需要给出明确方案。

我的建议是先把这两个问题论证清楚。