ci(release): regenerate skill manifest on version bump

The release-cut "Bump package.json and tag" step bumped package.json but
never regenerated resources/skills/current-manifest.json, so its appVersion
stayed at the prior release. That drift shipped in v1.4.144-rc.1, rc.2, and
rc.3 (all carried an rc.1 manifest) and turns verify:skill-bundle-manifest
red on every branch after a cut, since that check runs in `pnpm lint` and
the PR `verify` job.

Regenerate the manifest right after `npm version` and stage resources/skills
into the release commit so the bundled manifest always matches the shipped
version. The generator is dependency-free (node builtins + git), so it runs
without a pnpm install, and the step's fetch-depth:0 checkout supplies the
tag history it reads.

.github/workflows/release-cut.yml

@@ -472,7 +472,15 @@ jobs:
           # message and tag name explicitly (avoids npm's `v1.2.3` prefix
           # assumptions and any lifecycle scripts that would run on bump).
           npm version "$VERSION" --no-git-tag-version --allow-same-version
-          git add package.json
+          # Why: regenerate the bundled skill manifest so its appVersion tracks the
+          # just-bumped package.json. Otherwise the committed manifest keeps the
+          # prior version and verify:skill-bundle-manifest (run in `pnpm lint` and
+          # the PR `verify` job) goes red on every branch after the cut — which is
+          # how v1.4.144-rc.1/rc.2/rc.3 all shipped an rc.1 manifest. The generator
+          # is dependency-free (node builtins + git) so it needs no pnpm install,
+          # and the fetch-depth:0 checkout above gives it the full tag history.
+          node config/scripts/generate-skill-bundle-manifest.mjs --write
+          git add package.json resources/skills
           commit_message="release: v$VERSION"
           if [[ "$EVENT_NAME" == "schedule" ]]; then
             commit_message="$commit_message [rc-slot:$SLOT]"