Simplify pkg/permissions: extract helper, reduce type cases, remove redundant checks

[dgageot]

• Extract matchAny helper to DRY up the three identical loops in CheckWithArgs
• Simplify argToString by removing redundant bool/int/int64 cases (handled by default)
• Collapse float64 branch to a single fmt.Sprintf(%g) call, drop strconv import
• Remove redundant nil args guard in matchToolPattern (nil map indexing is safe)
• Fold escaped-asterisk check into ContainsAny in matchGlob

Assisted-By: docker-agent

[docker-agent]

Assessment: 🟢 APPROVE

This refactoring successfully extracts the matchAny helper and simplifies type handling. The code is correct and safe. A few minor observations about comments and edge cases are noted inline, but none affect correctness.

[docker-agent]

Low Severity: Misleading comment

The comment states "indexing a nil args map is safe in Go", but the code doesn't index a nil map—it iterates over argPatterns and reads from args. When args is nil and argPatterns is non-empty, the exists check at line 184 returns false, causing an early return at line 185.

The behavior is correct (matches the old explicit nil check), but the comment is misleading. Consider clarifying:

// All argument patterns must match (reading from a nil map returns zero value and false for exists check)

[docker-agent]

Low Severity: Overly broad backslash check

The new code includes backslash in ContainsAny to catch escaped asterisks, but this prevents the prefix optimization for ANY pattern with a backslash in the prefix, not just those with escaped trailing asterisks.

For example, path\to\dir* would have used the prefix optimization in the old code (doesn't end with \*), but now falls through to filepath.Match (prefix contains backslashes).

This is safe (filepath.Match handles escaping correctly), but more conservative than before. The comment could be clearer about this trade-off.

[docker-agent]

Low Severity: Behavioral change for custom types

The simplified argToString now uses fmt.Sprintf("%v", v) for bool/int/int64 instead of explicit formatting. This works correctly for built-in types, but changes behavior for custom types that implement fmt.Stringer.

For example, a custom type wrapping int with a String() method would now call String() instead of formatting as a decimal number.

This is unlikely in practice (tool args are typically JSON-unmarshaled primitives), but worth noting as a subtle behavioral change.