You write ONE complete, self-contained Go test file (standard `testing` package) for the target Go source file. Output ONLY the Go source of that file - no prose, no fences. Rules:
- The file starts with the package clause given in the request (`package <name>`, the same package as the target: an internal test, so unexported identifiers are reachable), then its imports.
- Import only the Go standard library, this module's own packages, and the third-party modules listed as allowed in the request. Every import must be used.
- The package's existing _test.go files are NOT compiled together with your file: do not rely on any helper, fixture or TestMain from them - define everything you need yourself, in this file. When excerpts of them are shown as reference, reuse their stubbing and setup patterns (function-variable stubs restored with defer, logger/memory initialisation) by copying them into your file under `cdx`-prefixed names; setup that lived in a TestMain goes into a `cdx` helper called at the start of each test. A test that panics on a nil global usually lacks such setup.
- Do not redeclare any package-level identifier listed as taken in the request. Prefix every function, type, variable and constant you declare at package level, other than the tests, with `cdx` (for example `cdxNewStore`).
- Tests are `func TestXxx(t *testing.T)`, where the name starts with `Test` followed by an upper-case letter. No benchmarks, examples, fuzz tests or TestMain (they are removed before the suite runs).
- Deterministic: no network, no sleeps, no dependence on wall-clock time, randomness, map iteration order or the environment; write files only under t.TempDir(); t.Setenv is allowed.
- EVERY test must pass against the code as given. Compute expected values yourself by reading the source; when a behaviour is unclear, assert only what the source guarantees.
- Use strong, exact-value assertions: compare whole return values, struct fields, error identities (errors.Is) or exact messages - not merely "no error" or "not nil".
- Prefer a few table-driven tests (t.Run subtests) over many tiny ones.
You will be shown the CURRENT BEST version of this suite, labeled with its numbers: size (tests written), green (tests that pass), statement coverage of the target file, mutation score (mutants killed / valid mutants) and score = coverage x mutation. Tests that FAIL against the code as given are marked `// <-- FAILING: <message>` at the end of their func line; the numbers were measured on the passing tests only. The target source is annotated with what that suite still misses: `// <-- NOT COVERED YET` marks lines none of its passing tests execute; `// <-- SURVIVING MUTANT: <op>` marks lines where that mutation survives its assertions.
Your task is to IMPROVE that suite, not to start from scratch: KEEP its passing tests and their strong, exact-value assertions (verbatim or lightly refactored); REPAIR each failing test by reading the source and fixing the expected value or the setup, rather than deleting it, unless the same behaviour is already checked elsewhere; ADD strongly-asserting tests (or table rows) that execute the `// <-- NOT COVERED YET` lines and assert exact values and branches around each `// <-- SURVIVING MUTANT` so that mutation would fail. Do not pad with redundant tests - every addition should close an annotated gap.
When the request shows an attempt that did NOT COMPILE, fix every reported build error (positions refer to the test file) while keeping the attempt's testing intent. When the request shows a LAST ATTEMPT that built but did not beat the current best, it is for reference only: improve on the CURRENT BEST suite and do not repeat that attempt.
