fix: don't panic when redact.Set replaces an existing store

[ankit090701]

Description

redact.Set panicked if it was called a second time in the same process. This breaks a documented, intended use case: embedding syft as a library and constructing/executing cli.Command(id) more than once (see the linked issue and https://stackoverflow.com/questions/77387892/unable-to-call-anchore-syft-library-command-multiple-times-when-embedded-in-go-a).

AppClioSetupConfig (cmd/syft/internal/clio_setup_config.go) registers a clio initializer that calls redact.Set(state.RedactStore) on every Execute(). Each call to cli.Command(id) gets its own freshly-constructed clio.State, and thus its own new RedactStore - so the second time a consumer executes a command in the same process, redact.Set always panicked with "replace existing redaction store (probably unintentional)".

Looking at the sibling singleton packages in internal/, bus.Set and log.Set both just overwrite their package-level singleton on repeated calls, no questions asked - redact.Set is the only one of the three that panics on replace. This PR brings it in line with its siblings.

I confirmed this is still present on current main by reproducing the exact stack trace from the issue via cli.Command(id) + Execute() called twice in a row (executing the scan subcommand against a temp dir, twice) - it panics at internal/redact/redact.go:11 through the identical code path described in the issue (clio.(*application).runInitializers -> PostLoad -> fangs.postLoad/loadConfig -> setupCommand -> cobra Execute).

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have added unit tests that cover changed behavior
• I have tested my code in common scenarios and confirmed there are no regressions

Testing

• Added TestSet_ReplacingExistingStoreDoesNotPanic (internal/redact/redact_test.go), which sets a store, adds a redaction, replaces the store, and confirms: (a) no panic, (b) the new store doesn't inherit redactions from the replaced one, (c) the new store works normally going forward.
• Verified by reverting just the redact.go change: the test fails reproducing the exact panic message from this issue.
• Additionally verified end-to-end (not included in this PR - a temporary local test) by calling cli.Command(id) twice, executing scan dir:<tmp> -o json both times: panics with the identical stack trace as the issue on unmodified code; passes cleanly with the fix.
• Ran the full internal/... and cmd/syft/... suites. The only failures are pre-existing and environmental (this sandbox has no docker or zip binaries available, and runs as root which bypasses a permission-denied test in internal/cache) - unrelated to internal/redact, which has no relationship to any of those packages.

Issue references

Fixes #2285