ci: the destructive-wipe job could go green having run nothing

Two independent ways this job's only real assertion could vanish silently.

1. `cargo test <filter>` is a SUBSTRING match with NO floor. Rename the test --
   dropping just `the_` from `wipes_the_entire_namespace_destructively` is
   enough -- and the filter matches zero tests:

     running 0 tests
     test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
     exit status 0

   The job goes green, having stood up a dedicated valkey/valkey:8 service
   container to run nothing at all, and because the test is `#[ignore]`d no other
   job covers it either. The step now asserts `test result: ok. 1 passed`, so a
   rename fails loudly instead of quietly deleting the coverage.

   Deliberately NOT `--exact`: the `1 passed` floor is the load-bearing half and
   cannot break on a guess about the module path.

2. `plugin_path()` in the plugin's e2e tests was the only one of the ten sibling
   plugin repos without the `is_none() && CI -> panic!()` guard -- while
   `valkey_url()` seventeen lines below it in the same file has it. Demonstrated
   rather than assumed, with the cdylib absent:

     running 3 tests
     test admin_api_installs_the_valkey_plugin_and_writes_land_in_real_valkey ... ok
     test load_and_exercise_valkey_plugin_bad_config_fails_over_abi ... ok
     test load_and_exercise_valkey_plugin_persists_to_real_valkey_across_reopen ... ok
     test result: ok. 3 passed; ... finished in 0.00s

   Three tests "passed" in 0.00s without their subject existing. It now checks
   both the uplifted target dir and target/deps (a bare `cargo test` uplifts to
   neither for this crate), and refuses to skip under CI.

Author: MattJackson

.github/workflows/ci.yml

@@ -84,4 +84,19 @@ jobs:
         working-directory: store-valkey-repo/store-valkey
         env:
           VALKEY_URL: redis://localhost:6379/0
-        run: cargo test -- --ignored --test-threads=1 wipes_the_entire_namespace_destructively
+        run: |
+          set -euo pipefail
+          # FLOOR ASSERTION on the number of tests that actually ran. `cargo test <filter>` is a
+          # SUBSTRING match with no minimum: rename the test (dropping "the_" is enough) and the
+          # filter matches ZERO tests, cargo prints "running 0 tests / test result: ok" and EXITS 0.
+          # This whole job — and the dedicated valkey/valkey:8 service container it stands up — then
+          # goes green having run nothing, and because the test is #[ignore]'d no other job covers
+          # it either. Requiring "1 passed" is what makes the rename fail loudly instead.
+          out="$(cargo test -- --ignored --test-threads=1 \
+                 wipes_the_entire_namespace_destructively 2>&1 | tee /dev/stderr)"
+          grep -qE 'test result: ok\. 1 passed' <<<"$out" || {
+            echo "::error::the destructive-wipe test did not run (renamed, moved, or filtered out)." \
+                 "The filter matched no tests and cargo exited 0. Re-point the filter at the test's" \
+                 "current name — do NOT relax this assertion." >&2
+            exit 1
+          }

Cargo.lock

@@ -41,11 +41,39 @@ const TEST_SIGNING_KEY: &str = "0123456789abcdef0123456789abcdef0123456789abcdef
 /// under `cargo test` (which builds the whole package including the cdylib target before running
 /// tests) it is always present, so this only guards against unusual invocations.
 fn plugin_path() -> Option<std::path::PathBuf> {
-    let exe = std::env::current_exe().ok()?; // .../target/<profile>/deps/e2e-<hash>
-    let profile_dir = exe.parent()?.parent()?; // .../target/<profile>
-    let name = plugin_library_filename("busbar_store_valkey_plugin");
-    let candidate = profile_dir.join(&name);
-    candidate.exists().then_some(candidate)
+    let candidate = (|| {
+        let exe = std::env::current_exe().ok()?; // .../target/<profile>/deps/e2e-<hash>
+        let profile_dir = exe.parent()?.parent()?; // .../target/<profile>
+        let name = plugin_library_filename("busbar_store_valkey_plugin");
+        // Check BOTH the "uplifted" <profile>/<name> copy and the raw <profile>/deps/<name>
+        // compiler output, newest wins: a bare `cargo test` does NOT uplift the cdylib to the
+        // top-level profile dir, only to deps/ (same fix already applied to store-postgres's,
+        // store-mysql's, auth-oidc's and webrequest-hook's equivalent helpers).
+        let uplifted = profile_dir.join(&name);
+        let raw = profile_dir.join("deps").join(&name);
+        [uplifted, raw]
+            .into_iter()
+            .filter_map(|p| {
+                std::fs::metadata(&p)
+                    .and_then(|m| m.modified())
+                    .ok()
+                    .map(|mtime| (p, mtime))
+            })
+            .max_by_key(|(_, mtime)| *mtime)
+            .map(|(p, _)| p)
+    })();
+    // Under CI a missing cdylib is a HARD FAILURE, never a silent skip — the same discipline
+    // `valkey_url()` below already applies, and the one every sibling plugin repo applies here.
+    // Without it the three tests gated on this helper skip to green in 0.00s when their subject
+    // disappears, which is the only over-the-ABI coverage of the valkey store path.
+    if candidate.is_none() && std::env::var_os("CI").is_some() {
+        panic!(
+            "the store-valkey plugin cdylib is not built under CI: `cargo test` must build it \
+             (checked both the uplifted target dir and target/deps). Refusing to silently skip \
+             the only over-the-ABI coverage of the durable Valkey store path."
+        );
+    }
+    candidate
 }
 
 /// The live `VALKEY_URL`, mirroring `busbar-store-valkey`'s own `live_store()` gating discipline