fix(find): keep unknown-flag errors stable when next arg is another flag

[mimilovesevelyn]

Summary

Fixes command/flag discovery so unknown flags do not consume subsequent flag tokens as their values.

Problem

When scanning args in Find/stripFlags, unknown flags that looked like value-taking flags could incorrectly consume the next token even when that token was itself another flag. This could change the resulting error to an unrelated command parse error (e.g. unknown command "foo") instead of the expected unknown flag error.

Root cause

The scanner consumed the next arg for --flag value and -f value patterns based only on NoOptDefVal checks, without confirming whether the flag actually exists when deciding to consume the next token.

Fix

• Added helpers to check whether a long/short flag exists in the active flag set.
• For unknown flags, only consume the next token if it is not another flag token.
• Applied this logic consistently in both stripFlags and argsMinusFirstX.
• Enabled the previously commented regression case in TestUnknownFlagShouldReturnSameErrorRegardlessOfArgPosition.

Files changed

• command.go
• command_test.go

Test notes

Go toolchain is unavailable in this execution environment (go/gofmt not found), so tests could not be run locally here. The PR includes a focused regression test case so CI can validate behavior.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}