[bkataru]

fix(deps): async-trait 0.1.92 for clippy::double_must_use

Fixes #86. Lockfile-only — unblocks #82 (RUSTSEC-2026-0285), which is the
only open, high-severity, fixable item in this repo.

Root cause

async-trait 0.1.89 pushes a bare #[must_use] onto every function it
generates:

// async-trait-0.1.89/src/expand.rs:69
method.attrs.push(parse_quote!(#[must_use]));

Those generated fns return Pin<Box<dyn Future>>, and both Pin and Box
are #[must_use] types. So clippy 1.99.0's double_must_use — "has a
#[must_use] attribute with no message, but returns a type already
considered as #[must_use]" — fires, and -D warnings makes it an error.

There is no #[must_use] in pawan's source. It is synthesised at macro
expansion. This is why a source grep for #[must_use] finds nothing and the
bug looks unreproducible. Clippy says so itself:

note: this error originates in the attribute macro `async_trait`
note: the return type is pinned boxed `futures::Future` trait object

0.1.92 removes that push. The fix is upstream, not a suppression — which
is why no #[allow(clippy::double_must_use)] appears in this diff.

The four sites (all #[async_trait], none in code added here)

crates/pawan-core/src/agent/backend/mod.rs:18:15
crates/pawan-core/src/agent/pool.rs:44:28
crates/pawan-core/src/coordinator/mod.rs:444:15
crates/pawan-core/src/tools/mod.rs:42:15

Verification — both directions, CI's exact flags

Toolchain clippy 1.99.0, the version CI resolves, on origin/main @ de893a9:

arm	async-trait	command	exit	sites
A (baseline)	0.1.89	cargo clippy --workspace --exclude eruka-web -- -D warnings	101	4
B (treatment)	0.1.92	same	0	0

Workspace build also clean (exit=0, 11m04s, all five crates).

The exit-code flip is the load-bearing part — 101 → 0, not merely fewer
printed lines. Same tree, same crate, same toolchain; only the macro version
differs.

Note on method: an earlier baseline of mine omitted -D warnings and
reported exit=0 while printing all four sites. A warning-level lint
exits 0 and would let a broken PR merge, so the numbers above are from
flagged runs matching ci.yml:36.

The larger issue this does not fix

pawan pins no toolchain. There is no rust-toolchain.toml on main, and
CI uses floating dtolnay/rust-toolchain@stable. Consequences, both observed
here:

• A clippy release turned main red days later with no commit to point at.
• Reproducing it needs 1.99.0, which is installed on the host — but the
  active toolchain is 1.95.0 and the default is 1.98.0, so cargo picks
  1.95.0 and the lint does not exist there. Two separate lanes ran the wrong
  toolchain and reported the lint as unreproducible.

Pinning the toolchain (or passing an explicit toolchain: to the CI action)
stops the whole class of "green until a toolchain release changes it". This
PR fixes one instance; that decision is separate and is the owner's.

Scope

Cargo.lock only, 1 file / +14 −3. async-trait = "0.1" already admits
0.1.92, so no Cargo.toml change. syn v3.0.6 comes along transitively.

[bkataru]

Subsumed by a single verified lockfile, posted on #83. This PR's CI cannot go green on its own: cargo audit fails on advisories outside its scope, and Check & Lint fails on clippy::double_must_use. Combining this bump with async-trait 0.1.92 + rustls 0.23.45 + quinn-proto 0.11.15 + crossbeam-epoch 0.9.20 + h2 0.4.16 + plist 1.10.1 takes the gate from 7 vulnerabilities to 1 with clippy exit 0 and 1826/1826 nextest green (lockfile sha 9dc234af6eba1997, lint result carries a planted-violation control at exit 101). No new PR opened — this needs review, not re-derivation. One caveat: h2 0.3.27 remains and no lockfile can clear it (see #81).

[bkataru]

Closing as duplicate — the async-trait 0.1.92 bump landed via #94 (merged, cleared the clippy wall). Thanks for the equivalent work.