Merge feat/durable-mcp-call-log into dev

The durable MCP tool-call log for the Valkey store, plus the cdylib freshness
guard and the first over-the-ABI coverage of those methods (the plugin was
cdylib-only, so its single e2e test had never actually run; the rlib addition
is what makes the artifact exist).

Conflict resolutions:
  * .github/workflows/ci.yml -- UNPINNED busbar_ref from the core branch
    feat/1.5.5-mcp-integrated back to ${{ github.base_ref || github.ref_name }}.
    The pin's own note said to move back once that core line merged; core dev
    now exports all four methods (append_mcp_call, list_mcp_calls,
    list_mcp_call_principals, purge_mcp_calls_before), so the precondition is
    met and CI tracks the branch again.
  * store-valkey/src/tests.rs -- both sides KEPT. dev added the shared Store
    contract conformance suite; this branch added the call-log tests. git
    aligned them as one conflict because both were inserted at the same point;
    taking either side alone would have silently dropped the other.

Author: MattJackson

.busbar-ref

@@ -1 +1 @@
-c8780349cf66d09b891478d50766b89dc1ff224c 1.5.3
+a0d5f7f194a0d44afa043229e3309549143ceb3b 1.6.0

.github/workflows/ci.yml

@@ -43,6 +43,11 @@ jobs:
       plugin_kind: store
       plugin_alias: valkey
       service: valkey
+      # UNPINNED from `feat/1.5.5-mcp-integrated` on merge to dev: that pin existed only because
+      # core `dev` did not yet carry the durable MCP tool-call log contract, and the pin's own note
+      # said to move back to the branch ref once that line merged. Core dev now exports all four
+      # methods (append_mcp_call / list_mcp_calls / list_mcp_call_principals /
+      # purge_mcp_calls_before), so the precondition is met and CI tracks the branch again.
       busbar_ref: ${{ github.base_ref || github.ref_name }}
       # base_ref FIRST: on a pull_request `github.ref_name` is '<number>/merge', not a branch
       # name, so this asked busbar for a branch called '5/merge' and the sibling checkout died

store-valkey-plugin/Cargo.toml

@@ -9,7 +9,16 @@ description = "The Valkey store as a droppable busbar plugin — a cdylib export
 license = "Apache-2.0"
 
 [lib]
-crate-type = ["cdylib"]
+# cdylib for the C ABI delivery; `rlib` is REQUIRED for `cargo test` to emit the cdylib artifact AT
+# ALL. With `cdylib`-only, cargo builds a trivial "0 tests" harness for this package under `cargo
+# test` and never produces the .dylib/.so — so `tests/e2e.rs`, the ONLY over-the-ABI coverage of the
+# durable valkey path, found nothing and silently skipped, reporting GREEN with zero coverage. The
+# sibling store-postgres-plugin/store-mysql-plugin/store-sqlite-plugin manifests already carry both
+# crate-types for exactly this reason; this one had drifted. Verified, not assumed: with `cdylib`
+# only, `cargo test -p busbar-store-valkey-plugin` leaves no
+# `target/debug/deps/libbusbar_store_valkey_plugin.dylib` even after touching src/lib.rs; with
+# `rlib` added, cargo emits it on every build that recompiles the lib.
+crate-type = ["cdylib", "rlib"]
 
 [dependencies]
 # busbar-store-valkey is now a SAME-REPO sibling crate (this plugin brings 100% of what it needs — the