fix: ignore non-command args after help flag

[happysnaker]

Summary

• ignore trailing positional arguments after an explicit --help / -h flag unless they resolve to an actual child command
• keep explicit help <command> behavior unchanged
• add regression coverage for root and subcommand help with positional args on either side of the help flag

Problem

Issue #2126 reports that --help currently breaks when a command also has positional arguments. For example, command ciao --help ends up trying to resolve ciao as a help topic and returns No help topic for 'ciao' instead of showing the command help.

The root cause is that helpCommandAction cannot distinguish between:

• the built-in help subcommand (app help foo), where a following token should still be treated as a help topic, and
• the help flag path (app foo --help ciao / app foo ciao --help), where extra positional args should be ignored unless they are an actual child command.

Fix

• tag the --help / -h path in the execution context before dispatching into helpCommandAction
• in helpCommandAction, only treat the first positional token as a help topic when:
  • the built-in help subcommand was invoked, or
  • the token resolves to a real child command, or
  • help was reached via the default/no-flag path
• otherwise, ignore the positional arg and show the current command help

This keeps existing explicit help <command> behavior intact while making the flag path match the expectation from #2126.

Testing

• added root-command regression coverage for myCLI --help ciao
• added subcommand regression coverage for both:
  • myCLI command ciao --help
  • myCLI command --help ciao

I did not wait for a full local go test ./... run to complete in this environment, so CI should be treated as the verification source of truth for the full suite.

Fixes #2126