Refactor: code-quality batch (method extraction, dedupe, STDERR migration)

[ydesgagn]

Summary

Resolves the Medium-severity code-quality / refactor findings from the deep code review. All changes are behaviour-preserving — the existing 321-example suite passes unchanged with no spec modifications, and RuboCop is clean across all 45 files.

Key changes:

• QUAL-001 — LanguageJobBuilder#add_language_job (127 LOC) split into build_setup_step, build_dependency_steps, build_mono_dependency_steps, build_licenses_step.
• QUAL-002 — RepositoryConfigurator#configure_branch_protection (122 LOC) split into augment_required_status_checks, log_codeql_languages, discover_xcode_cloud_checks, validate_required_checks!, required_checks_differ?, build_branch_protection_payload.
• QUAL-009 — Job::COPYABLE_PROPERTIES / Step::COPYABLE_PROPERTIES constants now default the copy_properties argument; the duplicated literal array removed from all 24 call sites across 7 builder/manager files.
• QUAL-010 — Workflow#deploy_needs / Workflow#deploy_if_statement replace the byte-duplicated deploy-condition block in aws_job_builder and code_deploy_job_builder.
• QUAL-012 / QUAL-013 — scattered language[:short_name] string equality centralized into extra_deploy_checks? / xcode_cloud_unit_tests? / needs_codedeploy_setup? predicates; Swift additional_checks built from SWIFT_DEPLOY_CHECK_FLAGS list instead of a literal.
• QUAL-021 — misplaced YARD block moved from excluded_dirs_from_config onto find_files_matching.
• QUAL-028 — Workflow#read defaults @on/@permissions/@env to {} (not []); the now-redundant is_a?(Hash) guards in application.rb dropped.
• BUG-010 — STDERR migration completed: bin/github-build.rb rescue output and the repository_configurator.rb MISSING/EXTRA diagnostic block now use warn.
• Incidental: QUAL-016 (or eliminated via a captured boolean) and QUAL-025 (class comments tightened to carry information).

Deferred to separate work: QUAL-017 (BuildContext — touches every builder constructor + spec) and COMPAT-002 (--strict_version_check rename is a breaking CLI change needing a product decision).

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 ?: Behaviour-preserving refactor; the existing 321-example suite already covers these paths and passes unchanged.
• 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