redis_utils: search_config is published unredacted, and redact_config's markers are narrower than effective_config's

[fcostaoliveira]

Recording an adjacent finding from the #264 review so nobody re-derives it. Not a leak today — filed as defence-in-depth and as documentation of why.

engine/redis_utils.rs has its own redactor, redact_config, with four markers (pass, auth, secret, token). It is applied to the CONFIG GET * output embedded in server_metadata, where it correctly blanks requirepass, masterauth and tls-*-pass.

search_config (FT.CONFIG GET *) is published unredacted. Checked whether that discloses anything: the only credential-shaped key RediSearch returns is OSS_GLOBAL_PASSWORD, and the module self-masks it (Password: *******), so nothing leaks today. The gap is that this depends on a module's masking behaviour rather than on ours, and a future RediSearch key carrying a secret would be published.

Two things worth doing, neither urgent:

1. Route search_config through redact_config as well — one call, no behaviour change today.
2. Note that redact_config's four markers are narrower than effective_config::is_secret's thirteen (which feat(results): record the environment knobs and declared config a run actually used #264 adds): pass/auth/secret/token miss API_KEY, ACCESS_KEY, PRIVATE_KEY, SIGNING_KEY, CREDENTIAL, SESSION, BEARER, PWD. If the two ever need to agree, they should share one predicate rather than drift — the artifact already contains both redactors' output side by side, and two different <redacted> spellings in one file invite exactly the "which one covers what?" confusion this cycle spent ten rounds on.

Context: server_metadata contributes ~1,400 server-supplied strings to a result file, so it is the largest single surface in the artifact and the one least covered by #264's guards, which are scoped to engine_params by design.