Environment-specific `outdated_mode`?

### Details

On my team, we would like to enforce that our dev environment is always up to date with main, but other environments such as staging and production don't have that requirement, as sometimes we need to branch deploy a hotfix branch there which will most definitely be out of date with main, so the outdated enforcement becomes a hindrance.

For a while we had just disabled outdated checks for all environments, but it's caused the occasional confusion when people accidentally deploy outdated changes to dev where that's unexpected 😅 so we're looking to go back to properly enforcing those rules.

Since the environment/command parsing all happens internal to the branch deploy workflow, I can't figure out a way to make the `outdated_mode` environment specific. For the time being I've implemented a bit of a workaround where I have my own step _after_ the branch deploy step that checks the `environment` and `is_outdated` outputs and responds accordingly, but it's a bit hacky, and has the side-effect of showing the "deployment triggered" comment before then displaying my own custom outdated comment, which certainly isn't ideal 😅

I'm wondering if this is something that would be feasible for the workflow to support internally?

Read the branch deploy workflow's internal environment and command parsing first, then trace how outdated_mode and the environment/is_outdated outputs are handled. Done means outdated enforcement can differ by environment within the workflow, without a follow-up step or duplicate deployment comment.

Written by the indexing model from the issue text.