Support parent command options after subcommands

[Copilot]

Allows parent command options to appear after subcommand names, so command subcommand -o is equivalent to command -o subcommand where -o belongs to the parent command.

Changes

Deferred option processing

• When deserializing a subcommand, parent options are detected, skipped, and saved to a stack
• After subcommand deserialization completes, parent processes saved options from the stack
• Uses FindParentOption() to identify which command an option belongs to during argument scanning

Conflict detection

• ParseCommandAndValidate() now checks for duplicate option names between parent and subcommand
• Throws ArgumentSyntaxException unconditionally if conflict detected, regardless of whether the option is used

Example

[GenerateDeserialize]
partial record TopCommand {
    [CommandOption("-v|--verbose")]
    public bool? Verbose { get; init; }
    
    [CommandGroup("command")]
    public SubCommand? SubCommand { get; init; }
}

// All of these now work equivalently:
ParseRaw<TopCommand>(["--verbose", "first"]);
ParseRaw<TopCommand>(["first", "--verbose"]);
ParseRaw<TopCommand>(["first", "--verbose", "-s"]);  // Mixed parent/child options

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Allow options after subcommands</issue_title>
<issue_description>For some command line

command -o subcommand

It should also be valid to say

command subcommand -o

In the case that -o is an option to both the command and subcommand, an error should be produced by the parser (unconditionally, even if a matching argument is never passed).</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Allow options after subcommands #18

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.