Add verify-package skill: side-effect-free local package verification (macOS + Windows, TUI + desktop)

[LIUXIN557]

Problem Statement

开发者在 macOS 和 Windows 两台设备上修改 ACECode 后，想在本地确认「打出来的包是好的」——文件布局、捆绑资源、可执行性——但没有一条现成路径：仓库里唯一的打包 skill（acecode-release）是有副作用的发布流水线（推 git、写共享更新服务器、仅 Windows），CI 的 package.yml 步骤需要人肉从 1300 行 YAML 里捞命令。macOS 侧完全没有任何 skill 覆盖。开发者要么跳过验证直接信任 CI，要么每次手工拼命令。

Solution

新增一个 verify-package skill：一条命令在本地完成「构建 → CI 同款 staging → 结构校验 → 实际拉起试跑 → 逐项 pass/fail 报告」，全程零发布副作用（不碰 git、npm、更新服务器、签名）。覆盖 macOS 和 Windows、TUI 和 desktop 两类产物。desktop 在 macOS 上直接验证构建出的 app bundle（无需 PKG/签名）；TUI 通过 staging 目录验证资源解析不降级。

User Stories

1. As a developer, I want to run one command that builds and stages a CI-equivalent package locally, so that I can verify packaging without reading CI YAML.
2. As a developer, I want the verification to have zero side effects (no git, no publish, no update server), so that I can run it anytime without fear.
3. As a Windows developer, I want TUI verification that stages share/acecode resources next to the exe and runs headless commands from the staging dir, so that resource resolution is proven non-degraded.
4. As a macOS developer, I want TUI verification with the same staging flow, so that the bare build-dir fallback (missing share/) is not mistaken for the real behavior.
5. As a macOS developer, I want desktop verification against the build output app bundle directly, so that I do not need a PKG or signing to validate the app.
6. As a Windows developer, I want desktop verification against the built desktop exe with its daemon adjacency checked, so that runtime daemon discovery is proven.
7. As a developer, I want desktop to be actually launched and then closed, so that GUI startup is proven, not just file presence.
8. As a developer, I want a web/dist freshness preflight that fails with the exact rebuild command, so that I never silently validate the embedded placeholder page.
9. As a developer, I want the models.dev registry checked for exactly three hash-matched files, so that packaged catalog resources match source.
10. As a developer, I want the seed bundle verified by the existing seed verification script, so that there is one source of truth for that check.
11. As a developer, I want a per-item pass/fail report with a final exit code, so that failures are immediately actionable in scripts and CI.
12. As a developer, I want the staging directory preserved after the run, so that I can manually poke the package.
13. As a developer, I want a --skip-build mode, so that I can re-verify an existing build in seconds.
14. As a developer, I want a clear error when desktop was not built because the desktop flag is off, so that I know to reconfigure instead of debugging a missing file.
15. As a developer, I want incremental builds, so that repeat runs take minutes, not a cold half-hour.
16. As an agent, I want a SKILL.md whose description triggers on local/verification wording and not on release/publish wording, so that "本地验证打包" routes here and not to the release skill.
17. As an agent, I want the skill mirrored to all four skill roots, so that any harness (.acecode/.claude/.codex/.agents) can invoke it after git pull.
18. As a maintainer, I want the python helper covered by a ctest script-contract test, so that regressions are caught by the existing unit suite.
19. As a maintainer, I want the helper to reuse existing seed verification rather than duplicating it, so that validation logic has a single source of truth.
20. As a developer, I want the report to distinguish expected fallbacks (bare build-dir TUI) from real failures, so that I do not chase documented non-bugs.

Implementation Decisions

• New skill directory verify-package under all four mirrored skill roots (.acecode/skills/, .claude/skills/, .codex/skills/, .agents/skills/), each containing SKILL.md + scripts/verify_package.py; content identical across roots.
• SKILL.md is instructions only: trigger description worded around 本地/验证/无副作用/预演, deliberately disjoint from acecode-release's publish/release/Jenkins vocabulary; per-OS per-target command blocks; report interpretation guidance; explicit "no release actions" guardrail.
• verify_package.py is a single cross-platform Python 3 script with an argparse CLI: target selection (tui / desktop / all, default all), --skip-build, repo/build/staging dir overrides. Exit code 0 only when every check passes.
• Flow: preflight (web/dist present; cmake available) → configure + build (MinSizeRel, BUILD_TESTING=OFF, desktop on; skipped under --skip-build) → staging replicating the CI Package step (copy binaries + READMEs, cmake --install of the models_dev_registry and default_seed_bundle install components into a staging prefix) → structural checks (models_dev exactly three hash-matched files; seed via subprocess to the existing seed verification script; desktop daemon adjacency on Windows / app bundle Resources layout on macOS) → runtime probes (staged TUI binary with an isolated user profile home: --version plus the models registry validation command, proving share/ resolution without touching the real user config; desktop launched, liveness-waited, then terminated) → per-item report.
• The script performs no git operations, no publishing, no signing, and never writes outside the repo/build/staging/temp areas.
• Test seam (single): the script's CLI boundary exercised via --skip-build; a bash contract test builds a fake repo tree (assets, web/dist marker, READMEs) and a fake build dir with stub executables (scripts responding to --version / registry validation; a stub desktop that exits promptly), then asserts exit codes, staged layout, and report lines for both positive and negative cases (missing web/dist, wrong models_dev file count, failing registry validation).
• The test registers in the existing script-test block of the tests CMakeLists so it rides the standard ctest suite; no C++ and no CI workflow changes.

Testing Decisions

• A good test here observes only external behavior: subprocess invocation of the CLI, its exit code, the staged filesystem layout, and the stdout report. No import-level unit tests of script internals.
• Module under test: verify_package.py, via a new bash script-contract test following the existing pattern for the macOS release scripts test and the Linux update-zip test (temp dir fixture, expect_status helper, grep-based report assertions).
• Negative cases are first-class: missing web/dist must fail with the rebuild command in the output; a mutated models_dev file set must fail; a stub whose registry validation fails must fail the run.
• SKILL.md itself is manually validated on one macOS and one Windows machine (consistent with repo guidance that non-C++ instruction assets are hand-verified); the mirrored copies must be byte-identical.

Out of Scope

• Installer-level verification: Windows Inno Setup, macOS PKG, self-update zips.
• Signing, notarization, or any Apple credential handling.
• npm package preparation, GitHub Releases, aceupdate.json, or the shared update server.
• Linux targets (CI-only for now).
• Running the C++ unit test suite.
• Package size budgets or CI enforcement changes.

Further Notes

• This skill complements acecode-release: verify-package is the side-effect-free pre-flight, acecode-release remains the publishing pipeline. Trigger vocabularies are deliberately disjoint so agents route correctly.
• A bare build-dir TUI run resolving only the embedded fallback is documented, expected behavior — the skill must teach this distinction rather than flag it as failure.