Make hand-maintained smoke.yml jobs required status checks

[ydesgagn]

Summary

Branch protection is generator-managed: collect_required_status_checks only walks the generated build.yml jobs, so jobs from a hand-maintained .github/workflows/smoke.yml are never in the expected list. The result is that adding the smoke checks to branch protection by hand makes the next github-build run fail on a checks mismatch (or, with --sync_required_status_checks, strips them again).

This teaches the generator to discover those jobs, mirroring the existing non-workflow check detection (the Vercel line right above the new code).

Key changes:

• lib/ghb/repository_configurator.rb: after the Vercel detection, if .github/workflows/smoke.yml exists, parse it with Psych and append each job to @required_status_checks using the job name (falling back to the job id when a job has no name). Added require 'psych'. Job names are read dynamically so renaming a smoke job needs no generator change.
• spec/ghb/repository_configurator_spec.rb: default-stub File.exist?('.github/workflows/smoke.yml') to false in the shared before (so existing examples are unaffected), plus a new context asserting the three discovered checks (two by name, one falling back to the job id) are appended after Build/Lint.

After this merges, run github-build ... --sync_required_status_checks against ci-actions once so the new contexts (Action contracts (all 28), Linter actions (disabled path), Variables action) are pushed into master branch protection; thereafter every regeneration keeps them required.

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