test(core): shared privacy filter test vectors for uteke-cloud parity (#1464, part 2a)

[ajianaz]

What

docs/privacy-filter-cases.json: the shared test vectors of the privacy filter (uteke_core::privacy::redact, merged in #1491), as uteke-cloud asked in its answer on uteke-cloud#218 ("publish the cases as a small shared test-vector file ... cloud can then pin parity in CI the way it does with core-contract.json").

• 35 cases: 12 that mask (every kind: github-token in both shapes, aws-access-key, bearer-token, jwt, private-key, api-key, and four env-secret forms, plus a mixed case that fixes the per-kind counts) and 23 inputs that must stay untouched (hashes, UUIDs, paths, URLs, ${VAR} references, placeholders, identifier-like values, and Rust code such as api_key: self.api_key.clone()).
• Each case is name, input (an array of fragments, joined without a separator, so the file holds no string a secret scanner would flag), expected text and kinds as [kind, count] pairs ordered by kind. The format field of the file says how to run it; the allowlist is empty.
• uteke-core pins it: the_shared_cases_file_matches_the_implementation reads the file at test time, checks text and kinds for every case, and that every expected text is a fixed point of the filter.

No behaviour change. It is part 2a of #1464; part 2b wires the filter into the write paths (config, metadata, audit event, strict mode), part 2c the transports, part 3 the docs.

Why

Cloud reimplements the same detection (code is not copied between the repos). One file both repos test against is what keeps [REDACTED:<kind>] and the masks identical, so a memory means the same thing in OSS and in cloud.

Testing

• cargo test -p uteke-core privacy: 12 pass (11 existing, 1 new); clippy is clean.
• Mutation check, then reverted: changing one expected text in the file (aws-access-key to aws-key) fails the test with the case name.

[github-actions]

🔍 Cora AI Code Review

✅ No issues found. Code looks good!

---

Review powered by cora-code · BYOK · MIT

[ajianaz]

Merging with code-scanning alert #788 still listed: it is anchored to the earlier commit 4ae0901 (no analysis was uploaded for the later head 3344146). The finding was that the fragmented vectors still look secret-shaped; the CHANGELOG and file claims were corrected and the file is excluded from Cora review in .cora.yaml (one data file, no rule loosened). Cora on the head commit: no issues found, 15/15 checks. Local deterministic scan (cora scan --no-llm and a no-LLM review of the PR diff): 0 issues.