ci: compile every bench target on every PR

[xilosada]

Stack 1 of 5. Base: feat/storage-cost-gates (#3660).

Why

Benchmarks rot faster than tests, because nothing runs them. PR #2203 shipped a bench that inlined the body of a private function; the function was later deleted and that bench would not compile today. Nobody noticed, because no job ever built it.

What

• A blocking bench-compile job: cargo bench --workspace --benches --no-run. Compiles every bench target, executes none. Timing on shared runners is too noisy to gate on; compilability is not.
• docs/benchmarking.md — the conventions every bench in this series follows, including why criterion never gates and what to do with a comparison table.
• [profile.bench.package.calimero-storage] debug-assertions = true. Without it cargo bench --workspace does not build at all: feature unification leaks calimero-storage's dev-only testing feature into bench builds, and that crate's release-safety guard (crates/storage/src/interface.rs:209) refuses to compile without debug assertions. Scoped to the one package; opt-level untouched.

Verification

• Gate proven to fire: injected a reference to a non-existent symbol into a bench, confirmed --no-run fails with E0425, reverted, confirmed clean.
• cargo clippy --workspace --all-targets --features calimero-storage/testing -- -D warnings clean — note this job newly lints every bench file.
• rustup run 1.88.0 cargo fmt --check clean.

Before merge

Benchmarks compile should be in branch protection. The Criterion trend and Compare against master jobs added later in this stack must not be.

[github-actions]

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[xilosada]

Pushed the storage-cost determinism fix — this is the Rust failure on this PR.

row_counts_are_deterministic_across_calls built its workload with UnorderedMap::new(), which mints a random entity id. A parent's children live in a hash trie (core#3633) whose descent depth follows that id's hash, so two runs of an identical workload read a different number of trie nodes while writing exactly the same set. That is the rows_written: 313 / rows_read: 1088 vs 1098 signature in the CI log. new_with_field_name gives the collection a deterministic id, which is what the property under test actually needs.

Measured on this branch, same command:

without fix:  0 pass / 6
with fix:     8 pass / 8

Applied as a cherry-pick rather than a rebase: the test exists on every branch in the stack including feat/storage-cost-gates, so the fix's natural home is the bottom — but cherry-picking onto each affected branch keeps your stack ordering untouched. When the stack is next rebased, git will drop the duplicates by patch-id. Same commit is on #3752.

Not stale-base and not flaky, in case either is in your notes: the tool is byte-identical across the stack, and it fails essentially always under CI's feature set.

https://claude.ai/code/session_014mxKpC4vXk9Bujuetq7KBk

[github-actions]

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.