Document workflow write transformations in architecture.md

[ydesgagn]

Summary

Clarifies the documented behavior of Workflow#write in docs/architecture.md. The previous one-line description did not reflect the actual transformations applied during workflow serialization, which could mislead maintainers about how GitHub references and tokens are handled.

Key changes:

• Expanded the write(file, header:) description to document the two transformations performed via rewrite_github_refs: rewriting ${GITHUB_*} references to ${{github.*}} in YAML values while preserving them in shell run: bodies, and substituting ${{secrets.GITHUB_TOKEN}} with ${{secrets.GH_PAT}} (except in the auto-merge workflow)

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 ?: Documentation-only change with no code impact
• 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