spec: define the minimum supported Rust version policy for the open source fleet

[pierrick-fonquerne]

Three dependency upgrades are currently blocked across the open source fleet because the declared minimum supported Rust version of 1.88 has fallen behind the ecosystem. The minimum supported Rust version is a public contract for a published crate, so raising it is a breaking change and deserves a written policy rather than a case by case decision taken under the pressure of a failing pipeline.

Observed constraints as of 2026-08-07:

Repository	Blocked upgrade	Required toolchain
eidosdb	redb 2.6.3 to 4.1.0	rustc 1.89
.github	octocrab 0.44.1 to 0.54.1, through cargo-platform@0.3.3	rustc 1.91
aerogram	cargo-deny-action 2.0.20 to 2.1.1	a 1.88.0 musl toolchain the action image does not ship

The third case is a distinct failure mode worth calling out: rust-toolchain.toml is honoured inside container based CI jobs, where the requested toolchain is simply absent. Pinning an exact patch version therefore couples the repository to whatever toolchains third party action images happen to preinstall.

Scope

• State the target minimum supported Rust version for the fleet and the maximum drift behind stable that is tolerated, expressed as a rule rather than a number (for example: stable minus two releases).
• Define the trigger and cadence for raising it, and the semantic versioning consequence for each published crate.
• Decide whether rust-toolchain.toml should keep pinning an exact patch version, given it also applies inside container based jobs, and whether supply chain jobs should opt out of it.
• Enumerate the repositories in scope with their currently declared rust-version.
• Document the path forward for each of the three blocked upgrades listed above.

Acceptance criteria

• The policy is written and stored where every open source repository can reference it.
• Every repository in scope declares a rust-version consistent with the policy.
• The relationship between rust-version, rust-toolchain.toml and container based jobs is stated explicitly.
• The version bump consequence for already published crates is stated.
• Each of the three blocked upgrades has a documented decision: proceed, defer, or abandon.

[pierrick-fonquerne]

Decision recorded by #29 / #37: the dependency fix keeps the current Rust 1.88 declaration and selects Octocrab 0.47.1 as the newest safe, fleet-portable target. The higher 0.54.x line was not used because its required JWT backend adds either an unpatched RSA advisory or an extra AWS-LC/NASM native toolchain.

This does not resolve the fleet policy question here: any MSRV increase should remain an explicit, coordinated decision rather than a transitive dependency-update side effect.