feat(snapshot s3): add --include-regex / --exclude-regex path filters

[mbevc1]

• Path filters on kosli snapshot s3 previously only supported literal prefix matching, so excluding (e.g.) every PNG in a bucket required enumerating each key. Add regex variants in the same style as the existing --exclude / --exclude-regex pair on snapshot ecs, snapshot lambda, snapshot k8s, and snapshot cloudrun.

• Also cancel old CI runs on on new push

[claude]

Claude finished @mbevc1's task in 2m 7s —— View job

---

Re-review after latest push

• Run static analysis (build, vet, mod tidy)
• Review code changes
• Post review feedback

Static Analysis

All clean — go build, go vet, and go mod tidy pass with no issues.

Review Summary

The author addressed all prior review feedback well:

• Pre-compiled regex — compilePathRegex now compiles patterns once in GetS3Data before the object loop, passing []*regexp.Regexp to shouldExcludePath. This is actually better than the existing resourceFilter.go which still recompiles per call.
• Multiple regex OR test — Added test cases for multiple patterns in a single slice (both include and exclude), verifying the OR semantics.
• Renamed objectMatchesPaths → objectMatchesFilter for clarity.

No issues found. The code is clean and ready to merge. Details:

Area	Assessment
Correctness	Logic is sound. shouldExcludePath properly ORs literal prefix + regex within the same direction, and blocks cross-direction mixing via MuXRequiredFlags in PreRunE.
Consistency	Follows the same mutual-exclusivity pattern used in snapshot cloudrun (snapshotCloudRun.go:104-108). Flag descriptions and help text are clear.
Testing	TestShouldExcludePath covers: no filters, literal include/exclude, regex include/exclude, multi-pattern OR, and mixed literal+regex within the same direction. TestCompilePathRegex covers nil/empty/valid/invalid inputs. Command-level tests cover all four cross-direction mutual-exclusivity errors. Solid coverage.
Performance	Regex pre-compilation means per-object cost is just MatchString, which is the right approach for large S3 buckets.
Security	Regex patterns come from CLI flags (user-controlled), not external input. No ReDoS risk from the patterns shown, and regexp (RE2) is linear-time by design.

Nice work addressing the review comments. LGTM.

[gsavage]

Looks good, @mbevc1