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

[spiffcs]

Thanks for the PR and linking the issue @ankit090701. I'm going to go check and see if we can get a fix done in CLO.

Yes the panic is entirely syft's (clio never panics), but the forced re-Set is a clio design consequence.

clio.New returns redact.NewStore() per application (clio/application.go:54), so every Execute() hands syft a different store to hoist into a global.

If we update clio and flip the ownership then the problem disappears instead of being papered over.

Something like:

// setup_config.go
type SetupConfig struct {
      ...
      RedactStore redact.Store
}

func (c *SetupConfig) WithRedactStore(s redact.Store) *SetupConfig {
      c.RedactStore = s
      return c
}

cc @kzantow for feedback on the potential clio change vs this PR landing in syft. If 👍 just say so and I'll take it on.

[kzantow]

This panic is intentional: if a store is replaced, there could be values that should be redacted which no longer get redacted. Removing this panic is not the right fix.

Based on the stack overflow link, it seems like you are using the CLI directly, but you should probably be using Syft as a library instead.