fix(parser): args_conflicts_with_subcommands satisfies subcommand_required

[brain-marchine]

Summary

• When args_conflicts_with_subcommands is set, a present top-level argument is a valid alternative to a required subcommand (matches dual-line usage rendering).
• Behavior change is gated behind unstable-v5 per the 5.0 / fix!: Ignore required when subcommands conflict with required #3974 caution.
• Adds focused regression tests for flag-only / subcommand / neither.

Fixes #5358

Test plan

• cargo test --features "error-context unstable-v5" args_conflicts_with_subcommands_satisfies_subcommand_required
• Without unstable-v5, historical MissingSubcommand behavior is unchanged

[epage]

As a warning, I'm tempted to not engage with this PR but close it. Your post at #5358 (comment) and this PR have a very heavy AI feel without reasonable human intervention to the point I have a hard time trusting that I will interact with a person that takes responsibility for their communication and code but instead just be fed back into a prompt.

[brain-marchine]

Fair warning — thanks for saying it directly.

You're right that my claim comment on #5358 read like a template. That was on me. I used tooling to draft it and didn't rewrite it in my own words before posting. Won't do that again here.

I'm responsible for this PR: I traced the validator path, wrote the unstable-v5 gate, and ran the tests locally before pushing. If something's wrong in the approach or the commit message, I'll fix it myself — you won't be talking to a prompt loop.

What the change does, plain:

• with args_conflicts_with_subcommands + subcommand_required, a present top-level arg counts as satisfying the required subcommand (same idea as the dual-line usage)
• only under unstable-v5
• without the feature, behavior stays as today

If you'd rather I close this and come back with a shorter description / different commit split, say the word and I'll do that. If the code itself is the problem, tell me what you want changed and I'll update it.