chore: upgrade project dependencies and toolchains

[leynier]

Summary

• Upgrade stable Rust and Dart/Flutter dependencies across desktop, mobile, shared packages, runtime and Cloud, including Rust 1.98.0 and Flutter Rust Bridge 2.13.0.
• Adapt crypto, Cloud APIs, Linux keyring and Firebase compatibility while preserving protocols, persisted data, supported OS minimums and terminal forks.
• Update lockfiles and generated bindings; retain desktop_updater 2.7.0 and document compatibility exceptions.

Validation

• Desktop: 3,414 tests plus four goldens; mobile: 633 tests. Analysis, shared packages, packager and generation reproducibility passed.
• Rust format, strict Clippy, crypto vectors and workspace suites validated; one documented intermittent PTY case passed on its isolated rerun. Cloud unit tests, four isolated PostgreSQL contracts and Docker build passed.
• Native builds and smoke checks covered Linux, Windows, macOS, Android and iOS, including secure-storage upgrade compatibility and real native dictation.
• Disposable hosted runners passed native clipboard tests on macOS/Windows and all 18 Windows host conformance tests. The temporary workflow was removed and disabled afterward.

Full results, skips, security advisories and deferred dependency migrations: validation report. The normal build, analysis and test checks passed for commit b7486f09, including pr-ready and cloud-ready. Pullfrog completed with no blocking findings. Follow-up commit d40be281 also synchronizes the agent setup Rust pin and preserves the Linux v3 target=default credential filter; its new isolated duplicate-entry regression fails before the fix and passes after it, and old/new credential interoperability, format and strict Clippy pass. The final commit is going through the hosted checks again.

No visual design changes. Compatibility review retains the old macOS/Windows keyring backends where migration could not be certified. The security audit found only the pre-existing paste 1.0.15 maintenance advisory and rsa 0.9.10 timing advisory, with no patched stable releases; their scope is documented in the report.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[pullfrog]

ℹ️ Minor suggestions only — nothing blocking. The load-bearing compatibility claims (SQLite native delivery after the sqlite3_flutter_libs removal, flutter_secure_storage 10 → 11, and the Linux keyring store swap) were independently verified against primary sources and all hold.

Reviewed changes

Reviewed the complete 69-file diff at b7486f0 (5 commits).

• Toolchain and bridge pins — Rust 1.96 → 1.98.0 synchronized across both rust-toolchain.toml files, rust/cargokit.yaml, the sccache action, cloud.yml, setup_windows.ps1 and the cloud Dockerfile; flutter_rust_bridge 2.12.0 → 2.13.0 with regenerated committed bindings (content hash unchanged at 1213617933, so the bridge API is identical).
• Rust crypto stack — sha2 0.11, hmac 0.13 (KeyInit), hkdf 0.13, chacha20poly1305 0.11 (&Nonce::from), x25519-dalek 3, rand 0.10 via UnwrapErr(SysRng), which preserves OS-backed randomness and the previous panic-on-hard-RNG-failure behavior. Known-answer vectors and the cross-language relay suite are unchanged and passing; the SHA-256 fingerprint helpers moved to hex::encode, which emits the same lowercase hex as the old {:x} formatting.
• Linux keyring swap — keyring v3 → keyring-core + dbus-secret-service-keyring-store on Linux only, through a shared native_credential_entry adapter that keeps the service/user mapping and per-attempt construction; macOS and Windows keep the certified v3 backends. Source comparison confirms v3-written entries stay readable; one behavioral delta noted inline.
• Cloud — reqwest 0.13 with the newly separate form feature, sqlx 0.9 feature renames (runtime-tokio + tls-rustls-aws-lc-rs), tower-http 0.7, base64 0.23, ed25519-dalek 3, and rand 0.10 for refresh tokens, enrollment codes and secrets. No protocol or auth-flow changes.
• Dart upgrades — routine bumps across desktop, mobile, shared packages and the packager. sqlite3_flutter_libs removal is correct: upstream 0.6.0+eol is a documented no-op and sqlite3 3.x build hooks bundle native SQLite on all three desktop platforms with no extra configuration on Dart 3.13. flutter_secure_storage 11.0.0 is safe for this codebase: every call site uses default options, v11 only removes deprecated algorithms that v10 already migrated, and the compileSdk = 37 pin matches upstream's requirement. The Firebase PlatformException tolerance and deniedPermanently mapping come with channel-level regression tests that exercise the new branches.
• Validation record — the new docs/dependency-upgrade-2026-08/ report, inventories and hosted-run evidence are thorough and honest about intermittents and scope exclusions; the temporary validation workflow is confirmed absent from .github/workflows/.

ℹ️ Nitpicks

• .agents/setup:9 still pins RUST_TOOLCHAIN="1.96" — the one pin the upgrade report's synchronization list misses (it enumerates toolchain files, Cargokit configs, CI, the Windows setup script and the cloud image). The same value feeds RUSTUP_TOOLCHAIN=1.96 into the portable_pty prebuilt build at .agents/setup:135. Repo builds override through rust/rust-toolchain.toml, so the fallout is limited to that provisioning path, but updating it would make the report's "synchronized" claim true.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using openai-compatible/glm-5.3-flash ｜ 𝕏}

[pullfrog]

✅ No new issues found. The new commit cleanly addresses both findings from the prior review, and the load-bearing crate-contract claims behind the keyring fix were verified against primary sources.

Reviewed changes

Reviewed the delta since the prior review at b7486f0: one commit (d40be281) touching .agents/setup, rust/alera-cli/src/native_credential_entry.rs, and the upgrade report.

• Rust provisioning pin synchronized — .agents/setup now pins RUST_TOOLCHAIN="1.98.0", completing the synchronization claim across all seven pin sites plus the cloud Dockerfile. The value also feeds the portable_pty prebuilt build via RUSTUP_TOOLCHAIN at .agents/setup:135; the separate PORTABLE_PTY_RUST_TOOLCHAIN="1.92.0" remains unchanged as documented.
• Linux keyring scoping restored — native_credential_entry now builds the Secret Service entry with target=default, restoring v3-equivalent matching. Verified against the dbus-secret-service-keyring-store 1.0.1 source: the modifier is written as an item attribute on create and included in the search backing every get/set/delete (search_attributes → get_unique_item), so a same-service/user item with a different target no longer produces Error::Ambiguous. This directly fixes the behavioral delta flagged in the prior review thread.
• Old/new interoperability holds — verified against the keyring 3.6.3 source: v3 wrote entries with a target="default" attribute and searched on target + service + username, so existing Alera entries match the new filter and new entries stay readable after a rollback.
• Regression test added — default_target_ignores_unrelated_credentials exercises read/update/delete against an item with identical service/username but target=unrelated, and would fail with Error::Ambiguous before the fix. It compiles in the Linux CI workspace run and is correctly gated (#[ignore] plus ALERA_KEYRING_TEST_DISPOSABLE=1) since it needs a real unlocked keyring; the isolated-session run procedure is documented in the upgrade report.
• Upgrade report updated — documents both fixes, the completed pin synchronization, and the disposable-session evidence for the credential probes.

One informational note, no action requested: keyring 3.6.3 also had a legacy fallback that re-searched the default collection without the target filter when the scoped search found nothing, recovering items carrying no target attribute. The new store has no equivalent, so such an item reads as NoEntry and the next sign-in creates a fresh entry, degrading gracefully through the existing 0600-file fallback. Since Alera introduced keyring at 3.6.3 (which always wrote the attribute), no Alera-written entry can hit this; only third-party items could, and the validation docs' interoperability probes don't cover that corner.

  ^{｜ View workflow run ｜ Using openai-compatible/glm-5.3-flash ｜ 𝕏}