Rename auto-merge workflow to auto-approve and remove legacy file (CI-002)

[ydesgagn]

Summary

The generated workflow is named "Auto-merge for code owners" but only approves code-owner PRs — it never merges (the merge step was removed in a prior commit). The misnomer surprises maintainers and any downstream automation expecting an auto-merge. This renames it to reflect what it actually does and ensures regenerated repos don't end up running two workflows.

Key changes:

• lib/ghb/auto_merge_manager.rb: workflow name → "Auto-approve for code owners"; job :enable_automerge/"Enable Auto-merge" → :auto_approve/"Auto-approve"; concurrency group auto-merge-* → auto-approve-*; output file → .github/workflows/auto-approve.yml; FileUtils.rm_f the legacy .github/workflows/auto-merge.yml on every run so no consumer keeps both workflows.
• lib/ghb/application.rb: workflow display name updated to match.
• lib/ghb/workflow/workflow.rb: token-rewrite skip guard widened from auto-merge to auto-(merge|approve) so the renamed PAT-based workflow is still excluded from the GITHUB_TOKEN→GH_PAT substitution.
• spec/ghb/auto_merge_manager_spec.rb: updated expectations + new test asserting the legacy file is removed.

Addresses code-review finding CI-002. Companion PR: Cloud-Officer/ci-actions (regenerated workflow + the batch).

Types of changes

• Bugfix (fixes an issue)
• New feature (adds functionality)
• Refactoring (improves code without changing functionality)
• Breaking change (incompatible changes)
• Build or security update (updates dependencies, libraries, or security patches)
• Code style or documentation update (formatting, renaming, or documentation changes)
• Other (please describe):

Checklist

• Unit tests added to validate my fix/feature
• I have manually tested my change
• I did not add automation test. Why ?:
• Database changes requiring migration with downtime or reprocessing of existing data
• The SOUP file lists the risk Level, requirements and verification reasoning associated with each library
• `readme.md` includes sections on introduction, installation, usage, and contributing
• `docs/architecture.md` includes sections on the architecture diagram, software units, software of unknown provenance, critical algorithms and risk controls related to PII and security
• Impact on PII, privacy regulations (CCPA/GDPR/PIPEDA), CIS benchmarks or security (availability/confidentiality/integrity); management must be notified

Further comments (if required)

On regeneration, every consumer repo's .github/workflows/auto-merge.yml is deleted and replaced by auto-approve.yml. The companion ci-actions PR contains the regenerated result; merging that PR is what actually removes the stale file from the consumer repo. No runtime behaviour changes — the workflow still only approves code-owner PRs.