fix: actually ?fix? the ghcr tag matching release tag

[nullable-eth]

🐳 Fix Docker Package Tags to Match GitHub Release Tags

Problem

GHCR package tags were not matching GitHub release tags, causing version confusion for users.

Expected: Release tag v1.1.1 → GHCR tag 1.1.1
Actual: Release tag v1.1.1 → GHCR tag 1.0.14 (unrelated version)

Root Cause

The Docker workflow was triggered by both main branch pushes and Git tag pushes, creating conflicting tagging strategies:

• Main branch pushes → Custom versioning (1.0.X based on commit count)
• Git tag pushes → Proper semantic versioning (1.1.1 from v1.1.1)

Since main pushes happened before release tags were created, the wrong versions were being published to GHCR.

Solution

• ✅ Removed main branch trigger - Docker workflow now only runs on Git tag pushes
• ✅ Split workflow into focused jobs:
  • build-release: Runs on Git tags (v*) → Creates proper semantic versions
  • build-pr: Runs on PRs → Build-only for testing
• ✅ Removed redundant dev builds since every merge creates a release
• ✅ Simplified workflow with clear job separation

Result

Now when you create release v1.1.1:

• 🎯 GHCR gets: 1.1.1, 1.1, 1, latest
• 🎯 GitHub release: v1.1.1
• ✅ Perfect match!

Impact

• 🔄 GHCR package tags now exactly match GitHub release tags
• 🧹 Cleaner workflow with no redundant builds
• 📦 Proper semantic versioning for Docker images
• 🚫 No more version conflicts or confusion

Testing

• Workflow syntax validated
• Job conditions verified
• Tagging strategy confirmed with docker/metadata-action docs
• Next release will validate the fix end-to-end

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)

---

Fixes: Docker package versioning mismatch with GitHub releases