feat(devcontainer-features-gitutils): ✨ move gitutils scripts to tomgrv/scripts, remove pecl

[tomgrv]

Summary

Part of a coordinated consistency pass across this repo, tomgrv/actions (#77, merged, released as v2.22.0), tomgrv/scripts (#3, merged, released as v0.3.0), and perspikapps/vps (#10).

• gitutils migration: src/gitutils/bin/'s ~32 git-* scripts now live in tomgrv/scripts as individual packages (feat(git-release-beta): ✨ add gitutils scripts migrated from devcontainer-features scripts#3) — one source of truth, mirroring the exact move common-utils already made. install.sh now bootstraps zz_use and pulls them in; gitutils keeps only the config/alias wiring and git-flow install/configure lifecycle.
• Shared release workflow: src/gitutils/stubs/.github/workflows/release-main.yml (the actual template every consumer repo's copy is stub-deployed from) now checks out the repo and calls tomgrv/actions' new release-promote composite action (feat: ✨ add release-promote composite action actions#77), pinned to v2.22.0, pulling git-release-beta/git-release-prod from tomgrv/scripts@v0.3.0. This repo's own root .github/workflows/release-main.yml is redeployed from that same stub, since this repo dogfoods its own features.
• Removes pecl entirely (rather than bringing it to v8 parity) — it was already flagged in docs/reviews/2026-08-repo-review.md §2.5 as the one feature diverging from the standard install-feature pattern. CLAUDE.md's "minimal reference" pointer moves to src/scripting/. All other references cleaned up; the historical audit doc's findings are left as-is with a dated addendum note rather than rewritten.
• Stale internal dependsOn pins: 7 features' own dependsOn blocks still pinned common-utils:7/gitutils:7/gitversion:7 even though those targets have been on major 8 for a while — bumped all to :8.
• Stale README self-install snippets: every feature's own README Quick Start snippet (plus the two in root README.md) still showed its pre-v8 self-install version — bumped to :8 (left scripting:1 alone, since that one's genuinely major v1).
• VS Code tasks: the stub's "🎈 Beta"/"🚀 Prod" local-CLI tasks are dropped now that release is fully automated via GitHub's "Run workflow" button.

Fixed during review

• validate-pr-title failed on the original PR title (feat(scope)!: ...) — devmoji's autocorrection inserts two emoji back-to-back for that breaking-change position, and commitlint's parser chokes on the result. Dropped the ! from the title; the breaking-change signal is still carried by the commit's BREAKING CHANGE: footer.
• release-promote was originally a workflow_call reusable workflow; restructured into a composite action per explicit direction, so it composes as a normal step instead of taking over the whole job. It went through several more live-verified fixes upstream (sibling-action resolution, a missing GitVersion toolchain, a missing git-flow install) before tomgrv/scripts' and tomgrv/actions' own real releases succeeded — see feat: ✨ add release-promote composite action actions#77 for the full history.

Cross-repo dependency

install.sh's zz_use calls and the release-main stub's scripts-ref/uses: refs are now pinned to the released tags (tomgrv/scripts@v0.3.0, tomgrv/actions/release-promote@v2.22.0) — both sibling PRs have merged and tagged.

Test plan

• bats src/gateway/tests src/common-utils/tests — all 24 pass (unaffected by this change, run as a regression check)
• Every touched devcontainer-feature.json validated as parseable JSON
• install.sh syntax-checked (sh -n)
• Workflow YAML and tasks.json files parse cleanly
• npx prettier --check clean on all changed files
• scripts-ref/uses: pinned to released tags

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dau8uW2rrctkyAxngdR1ix

[tomgrv]

validate-pr-title failed because check-pr-format's devmoji --text autocorrection, when given a title using the spec-correct breaking-change position (feat(scope)!: subject), inserts two emoji back to back (💥 for the !, ✨ for feat) — and that specific double-emoji subject then fails commitlint's parser (subject may not be empty, type may not be empty) in CI, even though it parses fine against a plain local npx commitlint invocation (some environment-specific resolution difference in @commitlint/config-workspace-scopes/parser versions I wasn't able to pin down further). The bang-before-scope form this repo's own commit.instructions.md example used (feat!(scope): ...) fares worse — commitlint doesn't recognize that position as a type/breaking marker at all and fails outright.

Fixed by dropping the ! from the PR title (devmoji then applies a single, clean ✨ and commitlint accepts it — verified locally, and it matches the pattern of every prior successful PR title in this repo's history). The breaking-change signal itself isn't lost — it's still in the squashed/merge commit's BREAKING CHANGE: footer, which is the spec's other, footer-based mechanism for the same thing.

One caveat: validate-pr-format only re-runs on opened/reopened/ready_for_review/synchronize, not on a title edit alone, so this check will keep showing its stale failure until the next real push to this branch (which will happen anyway once the sibling PRs merge and the pinned-ref TODOs get resolved here) — not pushing an empty commit just to force a green check.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dau8uW2rrctkyAxngdR1ix

---

Generated by Claude Code