Fix version-sync fragility across feature manifests

[tomgrv]

Problem

Feature versions are tracked in multiple places that must be kept in sync by hand:

• Each feature's own devcontainer-feature.json version field.
• Each feature's own package.json version.
• Transitive dependsOn pins in other features' manifests (e.g. "ghcr.io/tomgrv/devcontainer-features/common-utils:5").

This is fragile in practice — recent history shows a bump that had to be immediately reverted:

• 71b550d fix: update githooks and gitutils versions to 7
• ffc67c8 Revert "fix: update githooks and gitutils versions to 7"
• 9976a9f fix: update githooks and gitutils versions to 7 (redone)

Proposal

• Either designate a single source of truth (e.g. devcontainer-feature.json per feature) and generate/derive the others from it, or
• Add a CI check that fails if a feature's package.json version, devcontainer-feature.json version, and any dependsOn major-version pins referencing it are inconsistent.
• Document the intended bump workflow (this repo already uses .gitversion + commit-and-tag-version for conventional-commit-driven bumps — clarify how that interacts with per-feature manifest versions specifically).

Where this lives / sync note

This is primarily a root-level tooling/CI concern (a verification script + workflow), but it inspects and may need to touch each src/<feature>/devcontainer-feature.json and package.json — so any auto-fix tooling must write to the correct src/<feature> location to ride the split-repo sync rather than only updating root-level aggregates.

Acceptance criteria

• A documented or automated single source of truth for feature versions.
• CI catches a version mismatch before merge (would have caught the bump/revert cycle above).