Add production release flow with semantic versioning and unified SBOM handling

[Copilot]

Consolidates container build pipeline to handle development, staging, and production releases in a single action. Eliminates duplicate workflows while ensuring consistent SBOM/provenance generation across all build scenarios.

Changes

Release Flow Type

• Detects semantic versions (v1.2.3, v2.0.0-beta.1) from GitHub release events and tag pushes
• Generates multiple tags for stable releases: exact version, major.minor, and latest
• Pre-releases receive exact version tag only (no latest)
• Sanitizes Docker-incompatible + build metadata to - (v1.2.3+build.123 → v1.2.3-build.123)

Implementation

• Added is_semver_tag(), is_prerelease_version(), extract_major_minor(), sanitize_docker_tag() helpers
• Extended flow detection to handle release, create, and tag push events
• Updated PR comments with release metadata (🎉 emoji, description)

Usage

on:
  pull_request:
    branches: [main, dev]
  push:
    branches: [main, dev]
    tags: ['v*.*.*']
  release:
    types: [published]

jobs:
  build:
    steps:
      - uses: wgtechlabs/container-build-flow-action@v1
        with:
          platforms: ${{ startsWith(github.ref, 'refs/tags/v') && 'linux/amd64,linux/arm64' || 'linux/amd64' }}
          provenance: true
          sbom: true

Tags Generated

• v1.2.3 → v1.2.3, 1.2, latest
• v2.0.0-beta.1 → v2.0.0-beta.1
• v1.2.3+build.123 → v1.2.3-build.123, 1.2, latest

All existing flows (pr, dev, patch, staging, wip) unchanged. Backward compatible.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Enhance Container Build Flow for Unified Release & SBOM Handling</issue_title>
<issue_description>## Summary

Propose consolidating our container build flow to handle all image build and release scenarios, including production releases, with SBOM (Software Bill of Materials) and provenance support.

Background

• Currently, our release builds and regular dev/PR builds are handled in separate workflows (release.yml and build.yml, plus container-build-flow-action for CI).
• This split causes duplication of build steps, inconsistent SBOM strategies, and higher maintenance overhead.

Proposal

• Update or extend the container build flow so it can also handle official release builds (when a release is published or a production tag is created).
• Move all SBOM generation and provenance logic into the container build flow, making it SOLELY responsible for container image attestation for ALL scenarios (dev, PR, staging, release).
• Centralize multi-arch build support, semantic versioning/tagging for releases, Docker Buildx configurations, and registry handling in the action.
• This will reduce workflow duplication, streamline maintenance, and make our supply chain security more robust and DRY.

Key Considerations

• Workflow triggers (must work for PRs, dev/main, AND release events)
• SBOM & provenance: produced by container-build-flow-action only
• Semantic version docker tag logic for releases
• Multi-arch builds for production releases
• Community or marketplace users may benefit from a generalized solution

Impact

• Easier workflow maintenance
• Consistent SBOM/provenance generation
• One place for all container-related build improvements and security
• Simplified onboarding and iteration

---

Related to internal discussions and feedback from unthread-discord-bot#108 and workflow audit.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Enhance Container Build Flow for Unified Release & SBOM Handling #8

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.