[TASK] Refactor filters.yaml to use consistent naming convention for test and build filters

Description

The current filters.yaml uses inconsistent naming that makes it unclear what each filter controls. The backend filter is used as a catch-all for both build and test triggering, causing unnecessary test execution when only workflow files change.

Current Issues:

• Filter names don't clearly indicate their purpose (backend, frontend, build, jvm_unit_test)
• The backend filter triggers ALL backend tests even for workflow-only changes
• No clear naming convention makes adding new filters inconsistent
• Difficult to understand filter-to-workflow-step mapping

Proposed Solution:

Implement a consistent naming convention: {purpose}_{component}

Purpose Prefixes:

• test_* - Triggers test execution (e.g., test_integration, test_postman)
• build_* - Triggers build steps (e.g., build_backend, build_frontend)
• area_* - Triggers PR labels (e.g., area_backend) - already exists
• publish_* - Triggers publishing (e.g., publish_sdk_client)
• _* - Private anchors for internal use (e.g., _core_backend)

Example Refactoring:

# Before (Current)
backend: &backend
  - 'dotCMS/**'
  - '.github/workflows/**'  # ← Workflow changes trigger ALL tests

jvm_unit_test:
  - *backend

# cicd_1-pr.yml
integration: ${{ fromJSON(...).backend == 'true' }}  # ← Unclear

# After (Proposed)
_core_backend: &_core_backend  # Private anchor
  - 'dotCMS/**'
  - 'bom/**'

build_backend:
  - *_core_backend
  - '.github/workflows/**'  # ← Workflow changes only trigger build

test_jvm_unit:
  - *_core_backend

test_integration:
  - *_core_backend
  - 'dotcms-integration/**'

# cicd_1-pr.yml
integration: ${{ fromJSON(...).test_integration == 'true' }}  # ← Clear

Benefits:

• Self-documenting: filter name clearly indicates what it controls
• Granular control: workflow changes don't trigger unnecessary tests
• Consistent pattern makes adding new filters obvious
• Direct mapping between filter names and workflow inputs
• Reduces CI/CD time for non-code changes

Acceptance Criteria

• Define and document naming convention in filters.yaml header
• Refactor all test-triggering filters to use test_* prefix
• Refactor all build-triggering filters to use build_* prefix
• Convert shared patterns to private anchors with _ prefix
• Update cicd_comp_initialize-phase.yml filter lists
• Update cicd_1-pr.yml to use new filter names
• Update cicd_2-merge-queue.yml to use new filter names
• Update any other workflows referencing old filter names
• Verify workflow-only changes trigger builds but not tests
• Verify component-specific changes only trigger relevant tests
• Document migration strategy and validation checklist

Priority

Medium - Improves maintainability and reduces CI waste, but not blocking

Additional Context

Related Issues:

• #34669 - Fixed area_cicd labeling bug that revealed confusion in filter naming

Validation Test Cases After Migration:

• Workflow-only PR → Only builds, no tests
• dotCMS code PR → Builds + integration/postman/karate tests
• Frontend-only PR → Frontend build + frontend tests only
• CLI-only PR → CLI build + CLI tests only
• Multi-component PR → All affected builds + tests

Files to Update:

• .github/filters.yaml - Complete restructure with naming convention
• .github/workflows/cicd_comp_initialize-phase.yml - Filter list updates
• .github/workflows/cicd_1-pr.yml - Update filter references
• .github/workflows/cicd_2-merge-queue.yml - Update filter references
• Other workflows as needed

Design Documentation:
See detailed naming convention proposal in issue comments or related PR discussions.

Start with .github/filters.yaml and inspect how its current filter names are consumed by cicd_comp_initialize-phase.yml, cicd_1-pr.yml, and cicd_2-merge-queue.yml. Search the workflows for old filter references, then validate the listed workflow-only, component-specific, and multi-component cases. Done means the naming convention is documented, references are migrated, and the expected builds and tests trigger.