chore: dev → main（修复 navop-shell 打包：install_flow 的 App 入口按 database 特性门控） - #504

v0.23.0-beta.3 打包时 navop-shell（只带 shell/remote-desktop）在
`-D warnings` 下报 `run_install_with_progress_prompt_app` 与
`finish_install_app` 是 dead code：这两个函数只有
`database_driver_install.rs`（`#[cfg(feature = "database")]`）会调用，
但 `install_flow` 模块本身是 `any(database, remote-desktop)`。

- 两个函数加 `#[cfg(feature = "database")]`
- `gpui::App` 导入拆成独立 cfg 语句，避免 shell 构建报 unused import

`cargo test --all` 会把整个 workspace 的特性合并求值，而发版矩阵是
「一个产品 × 一个目标」各自编译，共享 crate（extension-runtime 等）
只按该产品的特性集求值。beta.1 ~ beta.3 三次失败都属于这一类：

- beta.1：`navop` 缺 `windows-native-rdp` 特性转发
- beta.2：navop-data 未门控 `terminal_view` 导入（E0432）
- beta.3：navop-shell 构建下 `install_flow` 两个 App 版本入口成死代码

新增 `product-check` job：按 release.yml 的产品 × 目标矩阵（navop
linux/macOS/Windows x64 + win32，navop-shell 与 navop-data 各
linux/macOS/Windows x64）逐个 `cargo check`，参数抄自 release.yml
的构建步骤（独立产品不传 feature；navop win32 是「默认集减
shell-plugins」），`-D warnings` 由 setup-rust-toolchain 提供。

验证：把 beta.2 与 beta.3 的缺陷分别还原到当前代码上，本 job 的
命令分别报出 `unresolved import terminal_view` 与两条 `never used`；
恢复后 navop / navop-shell / navop-data 三产品 0 warning 0 error。

`crates/windows_rdp_host/tests/contract.rs` 里硬编码了 CI gate 的 needs
列表与 ci.yml 关键步骤，新增 `product-check` job 后 Windows 发版构建在
这个契约测试上失败。断言改为包含 `product-check`，并补三条产品检查
job 自身的关键行（矩阵来源与 cargo check 命令），避免这个 job 被悄悄删掉。

beta.4 的构建全部通过，但打包阶段失败，两处都不是编译问题：

1) macOS 独立产品：`Resolve platform matrix` 用 `tr ' ' ','` 把两个矩阵拼在
   一起，`bundle_name` 里的空格被当成逗号，产物目录变成 `Navop,Shell.app`，
   随后的 `tar` 找不到包。改用参数展开各去一层方括号，字节原样保留。

2) Windows 全部四个 job：`navop.exe` 没有 `.rsrc`，校验步骤报
   「不可能携带内嵌清单」。产品拆分后资源嵌入留在 `crates/navop_app/build.rs`，
   而它现在是库：`cargo:rustc-link-arg` 只作用于本包 targets，嵌出来的资源
   到不了 `apps/navop*` 的 exe。改为三个二进制 crate 各自的 build.rs 调用
   共享的 `resources/windows/embed_app_resources.rs`。

顺带把这两类回归纳入 `script/test-release-packaging.mjs`：拼接矩阵的脚本会被
真实执行并断言 14 条条目与带空格的 bundle_name；同时断言资源嵌入留在二进制
crate（`crates/navop_app/build.rs` 不得存在）。44 个打包测试全绿。

`Build shape` 的 Windows 条目直接 `cargo check`，没有开发者命令行的环境，
`crates/windows_rdp_host/build.rs` 找不到 `VCToolsInstallDir` 直接 panic
（missing Cargo build variable VCToolsInstallDir），navop/navop-shell 的四个
Windows 条目全挂。release.yml 的构建步骤本来就有 `ilammy/msvc-dev-cmd`，
这里补上同一步：i686 用 x86 工具链，其余用 x64。

Git Bash 的 PATH 里 `link.exe` 是 GNU coreutils 的 link，会盖掉 MSVC 的链接器，
`cargo check` 编译 build script 时报 `/usr/bin/link: extra operand`，
Windows 的四个产品检查条目全挂。改用 `shell: pwsh`（仅 Windows 条目）。

顺带在 script/test-release-packaging.mjs 里锁住这条：断言 Windows 分支
先跑 ilammy/msvc-dev-cmd、检查步骤用 pwsh 表达式且不含 bash 的 set -o pipefail。

`shell:` 不支持 matrix 上下文，写成 `${{ matrix.platform == 'windows' && 'pwsh' || 'bash' }}`
会让整个 workflow 解析失败（Unrecognized named-value: 'matrix'），CI 直接起不来。
改为按平台拆两步、各自写死 shell：Windows 走 pwsh（避免 Git Bash 的 link.exe
盖掉 MSVC 链接器），其余仍是 bash。

`build-product-installer.ps1` 里 `$resolvedOutDir = Join-Path $repoRoot $OutDir`，
而 release.yml 传的是 `-OutDir "${{ github.workspace }}\dist-product"`，
Join-Path 拼出 `D:\a\navop\navop\D:\a\navop\navop\dist-product`，New-Item 直接报
「filename, directory name, or volume label syntax is incorrect」，
navop-shell / navop-data 的 Windows 安装包发版失败。

改为：绝对路径原样使用，相对路径才拼仓库根（-IconPath 同理）。