chore: 统一 npm 安装并停止追踪 lib

[wang-kaopu]

Closes #77
Addresses #83

背景

目前 dsh-genui 同时维护 npm 和 GitHub 源安装，但 GitHub 安装已经多次带来额外兼容问题：

• 插件更新失败后留下的“包名不一致”状态导致启动失败问题 #52：GitHub 源更新失败后留下旧 dependency key + 新 package name 的半更新状态；
• Package rename breaks installs pinned via github:omdsh-dev/dsh-genui (self-import by new name cannot resolve) #53：包名从 @omdsh-dev/dsh-genui 改为 @changfenhuang/dsh-genui 后，github: 安装直接出现加载失败；
• docs: explain GitHub install migration after package rename #54：为处理 Package rename breaks installs pinned via github:omdsh-dev/dsh-genui (self-import by new name cannot resolve) #53，又额外增加了一套 GitHub 安装迁移文档；
• [Feature] 请求发布到 npm registry — DSH Desktop 插件市场仅接受 npm 精确版本源 #59：DSH Desktop / 插件市场要求 npm 精确版本，GitHub 源无法作为正式市场安装目标，并进一步推动了 ci: 增加 npm 发布工作流 #61 的 npm release workflow；
• [Bug] 插件市场点「更新」失败：README 的 git+https 安装指令在无 git 环境报错（git+ 后一串乱码），市场更新未走 npm 路径 #83：当前市场更新仍可能从 README 选中 git+https，在未安装 Git 的 Windows 环境直接更新失败。

也就是说，GitHub 源已经不只是“多一种安装方式”，而是会持续产生安装、更新、包改名和市场兼容成本。

为什么统一到 npm

当前一些高 star DSH 项目已经采用类似模式：

• zhu1090093659/dsh-web-ui：正式安装全部走 npm，GitHub checkout 仅用于开发调试；
• omdsh-dev/DSH-better-sidebar：正式安装和更新走 npm package，源码安装单独作为开发流程；
• ccch1mneyyy/dsh-TUI：同样以 npm 一键安装作为主要发布方式。

因此这里也收敛为：GitHub 作为 source，npm 作为 installable release。

正式安装只保留：

dsh plugin --profile web add @changfenhuang/dsh-genui

本 PR

• README / README.zh-CN 删除 GitHub 源正式安装入口，只保留 npm；
• scripts/install.sh 改为 npm 安装，不再检查或依赖系统 Git；
• e2e 安装模式由 git 改为 npm；
• lib/ 改为纯构建产物并停止提交；
• 删除 CI / release 对 committed lib/ 的 freshness check；
• 继续保留 pnpm run check、build、verify-pack 和 release publish，npm 包仍然会在发布时完整生成并验证 lib/。

对 dsh-market 的改善

#83 中市场从 README 获取到了 Git 安装路径，导致已通过 npm 安装的插件在“更新”时反而走 Git。

统一 npm 后，仓库只向市场暴露一个正式安装目标：

@changfenhuang/dsh-genui

这样可以避免后续 catalog/market 再在 npm 与 Git 两种安装源之间做错误选择。

已有的 market 缓存数据可能仍需要重新抓取 / probe 一次，但仓库侧不再继续产生歧义。

仓库维护收益

停止追踪 lib/ 后，源码 PR 不再同时重写 lib/client.js 等 generated bundle：

src 变更
  ↓
CI build / test
  ↓
release 时生成 lib
  ↓
npm package

可以直接减少：

• 并行 PR 对 lib/client.js 的高频冲突；
• generated diff 对 code review 的干扰；
• 每个源码 PR 都必须同步构建产物的维护成本；
• bundler / TypeScript 升级产生的大量无业务意义 diff。

构建产物仍由 CI 和 release 严格验证，只是不再把它作为源码仓库的一部分长期维护。

@taekchef 这是一个破坏性更新，需要决策确认。

[taekchef]

同意方案 A:统一 npm 安装、停止追踪 lib/。README/脚本/e2e/CI 改动都核对过,与本意一致。感谢整理,合并!Closes #77