Don't require a matching creation rule when a key is given explicitly

[Pawansingh3889]

Addresses #1790 — sops --age <recipient> -e file (or --kms/--pgp/etc.) fails with error loading config: no matching creation rules found whenever a .sops.yaml exists somewhere up the directory tree but none of its creation rules match the target file, even though the explicit key should be sufficient on its own. Reported against 3.9.4; still reproduces on current main / 3.13.3.

(Note: one comment on #1790 also mentions --output not being matched against creation rules — that looks like a separate, related problem this PR doesn't touch.)

Root cause

keyGroups() already does the right thing: if the caller passes --age/--kms/etc., it sources keys straight from those flags without consulting the config at all. But three other call sites load the config unconditionally, before keyGroups() ever runs, and treat any loading failure as fatal:

• main()'s app.Action (~line 1949) — loads config purely to read EncryptedRegex/UnencryptedSuffix/etc.
• getEncryptConfig() (~line 2134) — re-loads it again, for the same settings.
• shamirThreshold() (~line 2576) — loads it a third time, just for ShamirThreshold.

Every value these three read from config has a safe zero-value default — none of them actually need the config to exist, they only need to not crash when it doesn't apply. The command dies in one of these three before ever reaching the code (keyGroups()) that would have worked fine with just the CLI-supplied key.

Fix

Export config.ErrNoMatchingCreationRules as a sentinel for that specific failure. At each of the three sites: if the error is that sentinel and the user supplied at least one key flag directly (the same condition keyGroups() already checks, now factored into a shared hasExplicitKeyFlags()), treat it as "no applicable config" instead of a hard error. A config that exists and does match is completely unaffected — this only changes the non-matching + explicit-key case.

Verification

$ sops --encrypt --age age1... --input-type dotenv --output-type dotenv .env > .env.encrypted
error loading config: no matching creation rules found          # stock 3.13.3

$ ./sops-patched --encrypt --age age1... --input-type dotenv --output-type dotenv .env > .env.encrypted
$ ./sops-patched --decrypt --input-type dotenv --output-type dotenv .env.encrypted
# decrypts back to the exact original .env content — full round-trip verified

go build ./... and go test ./config/... ./cmd/sops/... both pass unchanged. cmd/sops has no existing unit tests covering this area ([no test files]) — happy to add table-driven tests for hasExplicitKeyFlags/the three call sites if that's wanted before merge, just say the word on shape/location.