feat(calm-hub): tag Docker images with project version

[russlan23]

Description

Closes #2833.

Adds semantic version tags derived from calm-hub/pom.xml to all four CALM Hub Docker publication variants:

• standard: 0.7.6
• read-only static: 0.7.6-read-only-static
• native: 0.7.6-native
• read-only native: 0.7.6-read-only-native

The existing latest/custom, SHA, branch, and Git tag aliases remain unchanged. This gives consumers an immutable release-oriented tag without removing the current publication conventions.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📚 Documentation update
• 🎨 Code style/formatting changes
• ♻️ Refactoring (no functional changes)
• ⚡ Performance improvements
• ✅ Test additions or updates
• 🔧 Chore (maintenance, dependencies, CI, etc.)

Affected Components

• CLI (cli/)
• Schema (calm/)
• CALM AI (calm-ai/)
• CALM Hub (calm-hub/)
• CALM Hub UI (calm-hub-ui/)
• CALM Server (calm-server/)
• CALM Widgets (calm-widgets/)
• Documentation (docs/)
• Shared (shared/)
• VS Code Extension (calm-plugins/vscode/)
• Dependencies
• CI/CD

Commit Message Format ✅

The commit follows the repository's Conventional Commits format and includes a DCO sign-off.

Testing

• I have tested my changes locally
• I have added/updated unit tests
• All existing tests pass

Local validation:

• parsed all four changed workflow files as YAML;
• resolved and validated the current calm-hub/pom.xml version (0.7.6) as semantic numeric version data;
• ran git diff --check.

The Docker publishing jobs require repository credentials and are therefore left to GitHub Actions.

Checklist

• My commits follow the conventional commit format
• I have updated documentation if necessary
• I have added tests for my changes (if applicable)
• My changes follow the project's coding standards

[markscott-ms]

@jpgough-ms do you have comments on this?

[rocketstack-matt]

These version tags (0.7.6, 0.7.6-native, 0.7.6-read-only-static, 0.7.6-read-only-native) come from calm-hub/pom.xml, which isn't bumped automatically per commit/release. Docker Hub tags are mutable by default and this PR doesn't enable Immutable Tags on the repo, so every push to main between manual version bumps will silently overwrite the same tag with a different image build. That contradicts the PR description's claim of an "immutable release-oriented tag." Is the version bump expected to happen in lockstep with these publishes, or should Immutable Tags be enabled on the Docker Hub repo to actually guarantee that?

[russlan23]

Good catch — you're right. With the current main triggers, the Maven-derived tags would be mutable between version bumps, so the PR description overstates the guarantee.

I propose publishing the semantic tags only from an explicit CALM Hub release ref, validating that the ref version matches calm-hub/pom.xml. Ordinary main builds would continue publishing only the existing latest/SHA aliases. I don't see an established CALM Hub tag convention yet; would calm-hub-v<version> fit the intended release process, or do you expect a different release ref?

[rocketstack-matt]

@jpgough-ms thoughts on version convention?