fix: add reports_bucket_name as a parameter used in gtfs validator prerelease generation

[davidgamez]

Summary:
The reports_bucket_name is added as a parameter to the rebuild_missing_validation_report function. This is needed as in GTFS validator prerelease generation, the bucket should be pointing to the staging bucket instead of the production one.

In addition, all references to the environment variable named env were changed to environment to prevent confusion and misuse.

From our AI friend

This pull request standardizes the use of the ENVIRONMENT environment variable (replacing the previous ENV) across the codebase, updates related configuration and workflow files, and introduces a new option to override the GCS bucket used for validation report results. It also updates documentation and tests to reflect these changes.

Environment variable standardization:

• Replaces all usage of the ENV environment variable with ENVIRONMENT in application code, scripts, configuration files (.env.local), and GitHub Actions workflow files. This ensures consistency and avoids ambiguity in environment configuration across the project. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Validation report bucket override:

• Adds support for an optional reports_bucket_name parameter to allow overriding the default GCS bucket where validator results are stored. This is useful for testing or pointing production to a staging validator bucket. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]

Documentation updates:

• Updates the README and docstrings to document the new reports_bucket_name parameter and its intended usage. [1] [2] [3]

Test enhancements:

• Updates and expands tests to verify the behavior of the new ENVIRONMENT variable and the reports_bucket_name override, including new tests for default and custom bucket selection. [1] [2] [3] [4] [5] [6] [7]

These changes improve configuration clarity, make environment handling more robust, and add flexibility for validation report storage.
Expected behavior:

Explain and/or show screenshots for how you expect the pull request to work in your testing (in case other devices exhibit different behavior).

Testing tips:

Provide tips, procedures and sample files on how to test the feature.
Testers are invited to follow the tips AND to try anything they deem relevant outside the bounds of the testing tips.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with ./scripts/api-tests.sh to make sure you didn't break anything
• Add or update any needed documentation to the repo
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)