Add River for Rust

[bgentry]

Teams running River in Go sometimes have services in Rust that need to enqueue or work the same jobs. Right now their choices are to write raw SQL against River's tables, which is easy to get subtly wrong (unique keys, attempt errors, notifications), or to put a Go service in front of the queue. This PR adds a Rust implementation of River that shares the schema and job protocol with River Go on PostgreSQL and SQLite. A Rust service can insert jobs that Go workers run, work jobs Go inserts, and take part in leader election and maintenance alongside Go clients in the same database.

This PR is stacked on the conformance suite PR (#1435) and should be reviewed after it. The cross-language harness from that PR is how this implementation proves it's interoperable: the Rust crate added here is its default candidate.

All the code lives in a new rust/ workspace. The crates are versioned and released together, starting at 0.48.0-alpha.1 to match River Go 0.48.

• riverqueue is the client. It's built on Tokio and takes a caller-owned SQLx pool, without generics over the database or a driver trait. It has typed async workers that get a CancellationToken, and request builders for insertion (transactional, batch, unique, scheduled, pending), job and queue management, and transactional completion. The runtime fetches, completes in bounded concurrent batches, retries, snoozes, cancels, and rescues jobs the way Go does. It also runs leader election and the maintenance services: rescuer, cleaners, scheduler, reindexer, and periodic jobs with Go-compatible cron parsing. Hooks, middleware, error handlers, and retry policies follow Go's extension points.
• riverqueue-macros provides #[derive(JobArgs)], with compile-time errors for invalid kinds and unique options.
• riverqueue-migrate applies River's PostgreSQL and SQLite migration lines and shares the river_migration history with Go, so either language can migrate a database the other uses. Its migrations are mirrors of Go's files. syncrustmigrations generates them, and CI fails if they drift, so Rust never gets its own schema history.
• riverqueue-test has insertion assertions and work-once helpers, similar to rivertest.
• riverqueue-cli installs a riverqueue binary with migrate-* commands and bench.
• riverqueue-conformance (unpublished) serves the conformance adapter contract (adapter_version 22) with riverqueue. conformance/adapter/candidates/rust.json makes it the harness's default candidate and peer.

A few behaviors are deliberate and worth checking during review:

• Requests given the caller's transaction run directly in it and open no savepoint, which matches River Go after Avoid opening subtransactions when already in a transaction #1420. If a request fails after River has written to the transaction, for example because insert middleware throws, that write stays in the transaction for the caller to roll back. On PostgreSQL, a failed statement aborts the transaction. caller_transactions.rs covers both. There's no Rust equivalent of RIVER_USE_LEGACY_SUBTRANSACTIONS; callers who need partial rollback can open their own savepoint.
• Values that other engines read must be stored exactly. Unique key hash inputs are encoded the way Go's encoding/json encodes them, so 1.0 hashes like Go's 1, and unique columns, timestamps, and attempt errors match Go's format. Other JSON, such as args, metadata, and notification payloads, only needs to mean the same thing as Go's, so the crate has no raw-text APIs whose only purpose is to reproduce Go's exact bytes. Unit tests check unique keys and cron schedules against the Go-generated conformance fixtures, and the generator copies them into the crate because published tests can't read files outside it.
• YugabyteDB is detected per database from the server's version string and yb_enable_listen_notify. Without xmax, unique inserts use a river:unique_nonce. Without LISTEN/NOTIFY, clients send no notifications and poll for cancellations, like Go.

On CI, the Rust targets stay out of make lint and make test, so Go contributors don't need a Rust toolchain. A separate Rust workflow runs lints (including PostgreSQL-only and SQLite-only builds), docs, tests on each supported Rust version, cargo deny, packaging, and semver checks. It also runs SQLite conformance, and for PostgreSQL 14 through 18 it runs the PostgreSQL tests, mixed and insert-only conformance, and a ten-minute soak. A manual release-candidate workflow gates on performance and a one-hour soak, and a weekly workflow runs a six-hour soak.

Here's how to review it:

Commits	Notes
add the Rust migration crate, add the Rust JobArgs derive macro	Small and self-contained. A good warm-up.
add River's Rust client	This is the main commit, about 35k lines. It can't be split into smaller commits that each build, because the client, storage, pilot, and maintenance modules all depend on ClientInner and on each other. I'd suggest reading it in this order: lib.rs and README.md, then client/ (builder, insert, producer, completer), then database*/storage*, then maintenance/, then unique.rs and encoding*. docs/mixed-deployments.md explains what has to match between Go and Rust.
test the JobArgs derive… through test Rust extension points	Integration tests grouped by layer: macro, storage and parity with Go's rows, runtime, database faults and YugabyteDB, extension points and caller transactions.
add Rust examples, add Rust test helpers, add the riverqueue command	Separate crates and examples.
run the Rust client as a conformance candidate	The Rust adapter, about 4k lines, mostly a mapping from contract methods to client calls.
run the Rust crates and conformance in CI, keep Rust and workflow dependencies updated, document the Rust workspace	CI, Dependabot, the workspace README, and the changelog.

[bgentry]

Superseded by #1442, which merged the Rust port without the conformance suite. Conformance is being slimmed down and will come back as separate, smaller PRs.