Warn about creation rules with identical path_regex

[rishabhvenu]

Closes #2238.

Only the first matching creation rule is used. If two creation rules have the same path_regex, the second one can never be selected, and its settings (in the issue: encrypted_regex) are silently not applied. sops currently says nothing about this.

This follows the scope suggested in #2238 (comment) and #2238 (comment): only rules with an identical path_regex string are reported. Rules with different regular expressions that match the same files are not reported, and rules without path_regex are ignored. Which rule is selected does not change.

With the config from the issue, sops encrypt secrets.yaml now prints this on stderr (captured with stderr redirected to a file):

[CONFIG]	 time="2026-10-07T20:38:19-04:00" level=warning msg="creation rules 1 and 2 in \".sops.yaml\" have the same path_regex \"secrets.yaml$\"; only the first matching creation rule is used, so rule 2 has no effect"

Rule numbers count from 1. If a path_regex is used three times, rules 2 and 3 each get one warning that points at rule 1.

Implementation notes:

• path_regex is the only field of a creation rule that is used for matching, so comparing that string is enough to know the later rule is unreachable.
• The check runs in LoadCreationRuleForFile, after the config file is parsed and before a rule is matched. It does not run in loadConfigFile, because that is also called by LoadStoresConfig (twice per command for the input and output store), which would repeat the warning.
• sops updatekeys a.yaml b.yaml loads the creation rules once per file, so the config path is remembered in a package-level sync.Map and the warnings are shown once per config file per process. This is the same idea as showedConfigFileWarning in cmd/sops/main.go.
• The config package had no logger. I added one with logging.NewLogger("CONFIG"), like the other packages do. The alternative would be to return the warnings to the caller the way LookupConfigFile does, but LoadCreationRuleForFile is called from both cmd/sops/main.go and the updatekeys subcommand and its signature would have to change. I can switch to that if you prefer it.
• destination_rules use the same first-match logic. I left them alone because the issue is about creation rules. The same check could be added there if wanted.

Tests:

• TestFindDuplicatePathRegexes: table test for the detection helper (no rules, distinct regexes, different regexes matching the same files, rules without path_regex, one duplicate, non-adjacent duplicate, triple, two duplicated regexes).
• TestLoadCreationRuleForFileWarnsAboutDuplicatePathRegex: loads a config file with a path_regex used three times, checks that exactly two warnings are logged, that the first rule is still selected, and that loading the same config again for another file logs nothing. This test fails if the call in LoadCreationRuleForFile is removed.
• TestLoadCreationRuleForFileDoesNotWarnWithoutDuplicatePathRegex: no warning for overlapping but different regexes and for several rules without path_regex.
• The tests capture log output with github.com/sirupsen/logrus/hooks/test, which is part of the logrus module already in go.mod.
• Manually with a built binary and the config from the issue: sops encrypt and sops -e print the warning once, sops updatekeys -y on two files prints it once, sops decrypt prints nothing, and a config with secrets.yaml$ followed by .*\.yaml$ prints nothing. The encrypted output is the same as before (first rule applied).

Ran go build ./..., go vet ./..., gofmt -l config/, go test ./config/... ./cmd/... and go test -race ./config/. staticcheck ./config/ reports the same single existing finding as on main.

Not tested: the hcvault and kms unit tests need Docker and were not run, and the Rust functional tests were not run. Neither package imports config. No changelog entry and no documentation change are included; the first-match behaviour itself is unchanged.