fix(sdk): use as_chunks in capsule counterparty decode — unbreaks CI on clippy 1.98

[cryptskii]

Unbreaks the Rust CI job. One line of production code; the rest of this description is why it was invisible locally.

Not a regression from any recent PR

error: using `chunks_exact` with a constant chunk size
  --> dsm_sdk/src/storage/client_db/recovery.rs:1092
  = note: `#[deny(clippy::chunks_exact_to_as_chunks)]` implied by `#[deny(warnings)]`

The flagged line dates from the initial commit (1f60266c, 2026-03-19) and is absent from the diff of the PR whose CI reported it. What changed is CI's toolchain: chunks_exact_to_as_chunks is new in clippy 1.98, and dsm_sdk denies warnings crate-wide (lib.rs:90). Main was going red on the next push regardless of what merged.

The fix replaces the pattern rather than suppressing it

-    let mut ids = Vec::with_capacity(blob.len() / 32);
-    for chunk in blob.chunks_exact(32) {
-        let mut arr = [0u8; 32];
-        arr.copy_from_slice(chunk);
-        ids.push(arr);
-    }
-    Ok(ids)
+    Ok(blob.as_chunks::<32>().0.to_vec())

No #[allow]. as_chunks yields &[u8; 32] directly, so the scratch array and its copy_from_slice disappear — the lint was pointing at real redundancy. The existing blob.len() % 32 != 0 guard already rejects a remainder, so the discarded .1 is provably empty and behaviour is identical.

Why make lint was green while CI was red

Local clippy 0.1.96; CI's 1.98.0. A lint that does not exist locally cannot fire locally — so a local pass is silent about it, not clean. I have been reporting LINT_EXIT=0 in PR bodies as if it were equivalent to CI's lint; it is not, when the versions differ.

Compounding it: Homebrew's cargo shadows rustup's, so cargo clippy --version reported 0.1.96 even under rustup run stable (which is 1.97.1). Asking the shadowed binary gives the wrong answer about which toolchain would actually run.

Verified by reproducing the failure, not by assuming

Installed a pinned 1.98.0 toolchain (additive — the default stays 1.97.1) and positive-controlled it against the pre-fix code. It reproduces the CI error exactly.

This mattered: local 1.97 emitted nothing on that line. Verifying with it would have "confirmed" the fix while proving nothing.

CI aborts at the first error (due to 1 previous error), so one reported failure does not bound the work. Swept cargo clippy --all-targets -- -D warnings under 1.98 across the whole workspace — clean, exit 0. recovery.rs was the only occurrence, and grep confirms no constant-size chunks_exact remains anywhere.

Verification — three gates, each run separately with its own exit code

board             68 suites, 3811 passed, 0 failed, 19 ignored, WORKSPACE_EXIT=0
make lint (1.96)  LINT_EXIT=0, 0 errors, "Lint passed."
clippy 1.98       --all-targets -D warnings, CLIPPY198_EXIT=0, 0 errors

Follow-up worth taking separately

The tracked .github/instructions/verification.instructions.md says to run make lint, with no version-parity rule. A candidate is filed to add one: compare cargo clippy --version against the version in the CI log, invoke the rustup toolchain binary directly rather than the shadowed one, positive-control a newly installed toolchain against known-bad code, and check whether a CI-flagged file is even in your diff before treating the failure as your own.