[Sync] Update project files from source repository (4ee089a)

[mrz1836]

What Changed

• Removed the monolithic .github/.env.base file (550 lines) containing all GoFortress configuration defaults
• Split configuration into modular .github/env/*.env files organized by concern:
  • 00-core.env - Go version and module configuration
  • 10-coverage.env - Coverage tool configuration
  • 10-mage-x.env - MAGE-X task runner configuration
  • 10-pre-commit.env - Pre-commit hook configuration
  • 10-security.env - Security scanning configuration
  • 20-redis.env - Redis service configuration
  • 20-workflows.env - GitHub workflow settings
• Added .github/env/load-env.sh script to source environment files in correct order
• Added .github/env/README.md documenting the new modular environment system
• Updated .github/actions/load-env/action.yml to use the new load-env.sh script instead of direct .env.base loading
• Updated all workflow files to reference the new modular environment system
• Added .github/.yamlfmt for YAML formatting standards
• Updated documentation in .github/docs/workflows.md and .github/docs/repository-features.md to reflect modular configuration approach
• Updated tech conventions documentation for pre-commit and commit/branch standards

Why It Was Necessary

• The 550-line monolithic .env.base file was difficult to navigate, maintain, and understand which settings belonged to which tools
• Modular configuration allows teams to override only specific tool settings without duplicating the entire configuration file
• Alphabetically-ordered loading (00-, 10-, 20- prefixes) provides predictable precedence and makes dependencies between configuration sections explicit

Testing Performed

• Verified all 32 modified files show consistent references to the new .github/env/ directory structure
• Confirmed load-env.sh script implements proper precedence (numbered files, then .env.custom overrides)
• Validated that workflow files correctly invoke the updated load-env action
• Checked documentation accurately describes the new modular environment system and migration path

Impact / Risk

• Breaking Change: Projects relying on .env.base must migrate to the new modular structure or create .env.custom with their previous overrides
• Low Risk: The load-env.sh script maintains backward compatibility by supporting .env.custom overrides
• Configuration Clarity: Improved maintainability and discoverability of settings, reducing risk of misconfiguration
• Migration Required: Teams must review their .env.custom files to ensure compatibility with the new modular structure