bug: TempConf test helper derives non-unique temp filenames, causing parallel-test flakiness

[phaethix]

FerrumKV version

0.5.1 (commit ea9dbb7)

redis-cli version

n/a — this is a unit-test / CI defect, not a server runtime issue.

Server start command

n/a — reproduced via cargo test --all-targets (the default --test-threads parallelism).

Steps to reproduce

1. In src/cli.rs, the #[cfg(test)] helper TempConf builds its file path as:
   /tmp/ferrum-cli-<name>-<process::id()>.conf
2. Two tests that pass the same name to TempConf::new(...) therefore write to the
   same file. Under cargo test's default parallel execution, test A's TempConf Drop
   (which does fs::remove_file) can run while test B is still reading the file.
3. cargo test --all-targets intermittently fails with a "No such file or directory" panic.

This was hit in practice when two newly added AUTH tests both used name = "auth"; PR #34 CI
passed by luck, but the post-merge master CI run failed (run 29654028228).

Expected behavior

Each test's temp config file is isolated and lives for the lifetime of its own TempConf
instance, regardless of the name argument or parallel scheduling. Both tests pass
deterministically.

Actual behavior

Intermittent failure:

thread 'cli::tests::requirepass_cli_overrides_config_file' panicked at src/cli.rs:483:27:
called `Result::unwrap()` on an `Err` value:
"failed to read config '/tmp/ferrum-cli-auth-4479.conf': No such file or directory (os error 2)"

Root cause: std::process::id() is constant across the whole test binary, so the filename is
not unique per test — only per name. The current workaround (renaming the colliding tests to
distinct names) is fragile: any future test that reuses a name reintroduces the race.

Component

ci (test infrastructure)

Severity & impact

medium — non-deterministic CI failure. Wastes CI minutes and erodes trust in red builds; the
failure only manifests under parallelism, so it can slip through PR checks and break master.

Proposed fix (optional)

Make TempConf filenames inherently unique, e.g. append an atomic counter (AtomicUsize) or a
per-instance random/uuid suffix, so collisions are impossible regardless of the name argument.