fix: 统一 Node 版本文档为 >=24 <26 + Windows 安装器 pnpm 进度 spinner

[labulalala]

关联 Issue

Closes #1021

变更摘要

1. Node 版本文档统一（9 处）

项目代码和安装器已要求 Node >=24 <26，但文档和部分运行时代码仍写 Node 20，导致新用户按文档安装后版本不匹配。

文件	修改
README.md	Node.js 20+ → 24+
README.ja-JP.md	Node.js 20+ → 24+
README.zh-CN.md	Node.js 20+ → 24+
SETUP.md	>= 20.0.0 → >= 24.0.0
SETUP.zh-CN.md	>= 20.0.0 → >= 24.0.0
docs/features/F113-multi-platform-one-click-deploy.md	Node.js 20 / node@20 → 24 / node@24
desktop/service-manager.js	>= 20 → >= 24
desktop/scripts/build-mac.sh	fallback v22.12.0 → v24.16.0
packages/api/src/utils/cli-spawn.ts	注释示例 v20 → v24

2. Windows 安装器 pnpm 进度优化

scripts/install.ps1 的 Invoke-PnpmInstallWithCapturedOutput 函数改造：

• 实时 spinner：替换 Tee-Object，进度行（packages/xxx、.../xxx）原地刷新显示旋转动画 + 当前包名，非进度行（错误/警告）正常打印到新行
• 失败回显：pnpm 失败时将 capturedOutput 完整输出，避免 "The real error is above" 但上方无内容
• PS 5.1 兼容：spinner 状态用 hashtable 传递，解决 ForEach-Object 闭包中值类型变量不可变的问题
• 优雅降级：控制台不支持光标操作时（CI/重定向）静默跳过 spinner

测试

• PowerShell 语法检查通过（0 parse errors）
• 已在实际 Windows 环境运行 install.ps1，验证 spinner 实时显示和错误输出可见

🤖 Generated with Claude Code

[zts212653]

Maintainer triage:

clowder-ai#1021 is accepted as a bug/docs-runtime consistency issue. I verified the Node 24 floor against the repo state (package.json engines is >=24.0.0, CI is already using Node 24), and the F113 reference is a real feature-doc anchor.

Directionally this PR is welcome, but merge is not cleared yet because Test (Public) is red on the PR merge ref.

The failing tests are all in packages/api/test/install-script-error-classification.test.js and guard the Windows / Node 24 pnpm install exit-code plumbing from clowder-ai#987:

• Invoke-PnpmInstallWithCapturedOutput trusts $LASTEXITCODE over pipeline exceptions (DEP0169 tolerance)
• Invoke-PnpmInstallWithCapturedOutput calls resolved pnpm directly inside the captured pipeline
• Invoke-PnpmInstallWithCapturedOutput temporarily downgrades ErrorActionPreference during pnpm capture

Because this PR changes Invoke-PnpmInstallWithCapturedOutput from the previous Tee-Object capture path to a custom ForEach-Object spinner path, please update the implementation and tests together so the existing invariants remain explicit:

1. the direct $pnpmCommand @CommandArgs 2>&1 native-call path still preserves $global:LASTEXITCODE correctly;
2. the catch path still treats $global:LASTEXITCODE -eq 0 as success for benign pipeline/stderr exceptions;
3. the new spinner/captured-output behavior has regression coverage, not just a manual Windows run note.

Once the public tests pass, we can continue code review. No merge clearance yet.

[砚砚/gpt-5.5🐾]

[zts212653]

Thanks for getting CI green. I re-reviewed the current HEAD e4044be3.

Requesting changes for one blocking test-guard regression, not for the spinner direction itself.

Blocking finding:

packages/api/test/install-script-error-classification.test.js no longer proves that the real Invoke-PnpmInstallWithCapturedOutput catch path preserves the $global:LASTEXITCODE -eq 0 success escape hatch.

The new tests use body.indexOf('} catch {') and then search from that point onward. In the new implementation, the first } catch { is the small spinner capability probe (try { [void][Console]::CursorVisible ... } catch {}), not the pnpm pipeline catch block. From that point, afterCatch includes the normal success return (Ok = $global:LASTEXITCODE -eq 0) before the real pnpm catch block. That means a future edit could remove the $global:LASTEXITCODE -eq 0 check from the real pipeline catch path and these tests would still pass.

This is exactly the invariant that previously blocked this PR and protects the Windows / Node 24 pnpm exit-code plumbing related to clowder-ai#987, so it needs to stay precise.

Please tighten the tests so they anchor to the actual multi-line pnpm pipeline catch block, for example by slicing from the multi-line catch index you already detect, or by extracting the catch block around the # Two distinct scenarios reach this catch: comment / following finally. Also fix the extra duplicated regex argument in the second assert.match; the intended message string is currently ignored.

After that, I can re-review. The production direction still looks reasonable: direct $pnpmCommand @CommandArgs 2>&1 | ForEach-Object is preserved, $ErrorActionPreference remains scoped around capture, and the new failure re-emit behavior is aligned with the issue.

[砚砚/gpt-5.5🐾]

[zts212653]

Re-reviewed current HEAD c28e9b9.

The previous blocking point is fixed: the tests now anchor to the real pnpm pipeline catch block via the Two distinct scenarios marker and slice to the following finally, so they no longer accidentally pass by scanning from the spinner capability probe catch or the normal success path. The duplicated assert.match argument is also gone.

I also rechecked the production path against the #987/#1014 exit-code invariants:

• Invoke-PnpmInstallWithCapturedOutput still resolves pnpm up front and calls & $pnpmCommand @CommandArgs 2>&1 | ForEach-Object directly.
• $global:LASTEXITCODE is explicitly initialized before the native call and read on both success and catch paths.
• $ErrorActionPreference is downgraded only around captured pnpm execution and restored in finally.
• Failure output is captured and re-emitted, which matches the visibility goal from clowder-ai#1021.

All GitHub checks are green at this HEAD. Approving review. Merge/intake decision is still maintainer-owned because this touches installer/runtime plumbing.

[砚砚/gpt-5.5🐾]