ci: remove shared cache key to fix CI rebuild issue

[sanity]

Summary

Fixes #1929 by removing the shared-key: "rust-cache" parameter from both the test_all and clippy_check CI jobs.

Why

The CI was rebuilding dependencies despite reporting cache hits because both jobs shared the same cache key but compiled with different configurations:

• test_all: uses --no-default-features --features trace,websocket,redb
• clippy_check: uses default features and different target binaries

When jobs shared the same cache, cached artifacts didn't match the current build configuration's fingerprint, forcing full rebuilds.

What Changed

• Removed shared-key: "rust-cache" from test_all job (line 35)
• Removed shared-key: "rust-cache" from clippy_check job (line 72)

This allows rust-cache to automatically create job-specific cache keys based on job names, ensuring each job:

• Caches only its own build artifacts with correct feature flags
• Restores only matching artifacts on subsequent runs
• Eliminates unnecessary dependency rebuilds

Expected Outcome

After this change:

• First run on main: Both jobs build from scratch, each saves its own cache
• Subsequent runs: Each job shows cache hit and does NOT rebuild dependencies
• PR runs: Restore cache from main branch with minimal rebuilds

@iduartgomez please review

🤖 Generated with Claude Code

[AI-assisted debugging and comment]

[iduartgomez]

@claude @sanity lets monitor this, I remember we added the key for a reason, but I don’t remember the exact reason.

Let’s monitor that indeed it works as expected.

[claude]

Claude finished @sanity's task —— View job

---

Monitoring CI Cache Behavior

Thanks for the review @iduartgomez! I've analyzed the change and can help monitor this.

Tasks

• Check current CI status
• Review the workflow changes
• Research when shared-key was added
• Provide monitoring plan

---

Context: Why the shared-key was added

I traced the git history and found that shared-key: "rust-cache" was added when the CI workflow was created on October 3, 2025 (commit 3306d0f). The workflow file was new at that point, so the shared key was likely added with the intention of sharing cache across jobs to speed up builds.

The Problem

However, as identified in #1929, this caused issues because:

• test_all: compiles with --no-default-features --features trace,websocket,redb
• clippy_check: compiles with default features and different binaries

When both jobs share the same cache key, cached artifacts don't match the build configuration, forcing full rebuilds despite cache hits.

What to Monitor

Here's what to watch for in upcoming CI runs:

✅ Success Indicators

1. First run after merge to main:

   • Both jobs should build from scratch
   • Each job saves its own cache (look for "Post Rust Cache" steps)
   • Build times will be normal (not improved yet)

2. Subsequent runs on main:

   • Each job should show "Cache restored successfully"
   • Critical: Check build output - dependencies should NOT rebuild
   • Look for: "Finished" messages without long compile lists
   • Build times should be significantly faster

3. PR runs:

   • Should restore cache from main branch
   • Minimal rebuilds (only changed code)
   • Faster than first run

⚠️ Warning Signs

• Cache hits but still see long dependency compilation lists
• Both jobs taking as long as clean builds
• Errors about cache corruption or mismatches

How to Check

In the CI workflow runs:

1. Expand the "Post Rust Cache" step - should show cache being saved for each job
2. Check the "Build" step output - look for how many crates are compiling
3. Compare build times between first and subsequent runs

Current Status

The current CI run is in progress:

• ✅ Clippy: Completed successfully
• ⏳ Test: Still running
• ✅ Fmt: Completed successfully

This is the first run with the new cache configuration, so both jobs are establishing their own caches.

I'll be happy to help analyze future runs if you see any issues! Just tag me with the workflow run link.

---

Branch: fix/ci-cache-issue-1929 | CI Run