[TASK] Modernize legacy Docker publishing workflows with modular cicd_comp structure

Description

The legacy workflows legacy-release_publish-dotcms-docker-image.yml and legacy-release_publish-docker-image-on-release.yml do not follow the updated modular CI/CD structure using cicd_comp_* shared workflows. These workflows provide ad-hoc build and deployment capabilities from any branch/tag, which is useful for testing release candidates, hotfixes, and feature branches.

Currently, the modern CI/CD structure lacks a workflow for building and optionally testing from any selected branch or tag on demand. This creates a gap in our CI/CD capabilities and requires maintaining legacy patterns alongside modern ones.

Key Issues:

• Legacy workflows use monolithic Maven build approach instead of phase-based pattern
• No support for Java version isolation (artifact suffixes)
• Missing artifact naming conflict prevention
• Inconsistent patterns compared to cicd_6-release.yml and other modern workflows
• No integration with existing cicd_comp_build-phase.yml and cicd_comp_deployment-phase.yml

Acceptance Criteria

• Create new cicd_manual_build-and-deploy.yml workflow following modern phase pattern (initialize → build → test → deploy → finalize)
• Support building from any branch, tag, or commit SHA via workflow_dispatch
• Implement artifact naming conflict prevention (auto-generate suffixes with Java version, custom tags, and git SHA)
• Reuse existing cicd_comp_build-phase.yml and cicd_comp_deployment-phase.yml components
• Add optional test execution after build
• Support multi-architecture Docker builds (AMD64, ARM64)
• Allow selection of Docker registry (DOCKER.IO, GHCR.IO, or BOTH) with GHCR.IO as default for test builds
• Support Java version override with automatic artifact suffix generation
• Add input validation to require custom tags for manual builds
• Document migration path from legacy workflows with deprecation timeline
• Update cicd_comp_deployment-phase.yml if needed to support custom tag suffixes
• Mark legacy workflows as deprecated with warning messages
• Add usage examples for common scenarios (hotfix testing, release candidates, Java version testing)

Priority

High

Additional Context

Current Legacy Workflow Features:

• Manual workflow_dispatch trigger for ad-hoc builds
• Multi-arch builds (AMD64, ARM64)
• Registry selection (Docker.io, GHCR.io, both)
• Custom tag support
• Full Maven build from source
• Complex version detection (trunk, LTS, snapshot, release)
• Repository dispatch support for enterprise updates

Modern Structure Benefits:

• Artifact caching and reuse across phases
• Java version override with artifact suffixing
• Separation of concerns (build vs. deploy)
• Consistent patterns with cicd_6-release.yml
• Better conflict prevention with naming strategy

Proposed Artifact Naming Pattern:

{version}{java-suffix}_{custom-tag}_{git-sha-short}

Examples:
- 25.01.00-java25_my-test_a1b2c3d
- 25.01.00-SNAPSHOT_hotfix-auth_e4f5g6h
- 25.01.00_custom-build_h7i8j9k

Related Files:

• .github/workflows/legacy-release_publish-dotcms-docker-image.yml
• .github/workflows/legacy-release_publish-docker-image-on-release.yml
• .github/workflows/legacy-release_comp_maven-build-docker-image.yml
• .github/workflows/cicd_6-release.yml
• .github/workflows/cicd_comp_build-phase.yml
• .github/workflows/cicd_comp_deployment-phase.yml

Analysis Document: See conversation thread for detailed comparison matrix and implementation plan.

Start by comparing the legacy workflows with .github/workflows/cicd_6-release.yml, cicd_comp_build-phase.yml, and cicd_comp_deployment-phase.yml. Trace the existing manual, multi-architecture, registry, and custom-tag behavior, then verify that the new workflow covers the listed phases, validation, examples, migration documentation, and legacy deprecation warnings.