Generate port conformance fixtures from River's Go implementation

[bgentry]

The Rust port checks several values against goldens recorded from River's Go implementation: unique key hashes and state bitmasks, cron next run times, snooze counts, job state bits, retry delay bounds, and notification payloads. The JavaScript port checks the cron and snooze ones too. Those goldens are hand-copied JSON files inside each port (rust/riverqueue/tests/fixtures/ and js/src/testdata/), and nothing in the tree generates them. When Go's behavior changes, the copies don't. The port tests keep passing against the old values, and nothing flags that the ports now disagree with Go.

For example, say a fix changes how Go escapes a selected river:"unique" field name before hashing it. Go's unique keys for those args change, but unique_keys.json in the Rust port still holds the old hashes, so Rust's golden test still passes. On a shared database, a job inserted by Go and the same job inserted by Rust now get different unique keys, so both rows are inserted when one should have been rejected as a duplicate. CI stays green the whole time.

This adds a nested github.com/riverqueue/river/conformance module with a generatefixtures command. It writes four files to conformance/testdata/ by calling River's own code: dbunique.UniqueKey and uniquestates.UniqueStatesToBitmask for unique_keys.json, the robfig/cron ParseStandard that River documents for periodic jobs for cron_schedules.json, the job executor's snooze rule for snooze_counters.json, and River's state, metadata key, notification, attempt error, and retry definitions for protocol_values.json. To make that possible, the executor's snooze increment moves into jobexecutor.NextSnoozeCount, which the executor now calls itself, and retrypolicy.DelayBounds reports the default retry policy's jitter range. The files use the shapes the ports already read, and cron and snooze are separate files so the JavaScript tests read exactly what they used to.

The fixtures are generated on demand and never committed. conformance/testdata/ is gitignored, and make generate/fixtures writes it. That keeps opaque generated JSON out of the tree and out of review diffs, and there's no "regenerate and commit" step to forget. Anyone working on River already has Go, and generation takes about a second. Every make target that runs port tests reading the fixtures (test/rust, test/rust/sqlite, test/rust/postgres, test/js) depends on generate/fixtures, so those tests always compare against what the current Go code produces. The Rust and JavaScript tests read the files at runtime rather than embedding them, and a missing file fails the test with "missing conformance fixture …; run make generate/fixtures" instead of skipping it. Reading at runtime also means Rust builds, clippy, and docs don't need the fixtures, so only the jobs that actually run tests set up Go: the Rust rust_versions and postgres jobs and the JavaScript unit test job. Both port workflows now also run when anything under conformance/ changes.

That still leaves the case from the example above: a Go-only change doesn't touch either port's path filters, so neither port's workflow runs and the drift merges anyway. Rather than widening those filters to every Go file, which would run both ports' full matrices on most Go PRs, a new Conformance workflow with a single job closes the gap. It runs only when Go files, go.mod/go.sum/go.work, the SQL queries the generator reads, or conformance/ change. It generates the fixtures and runs only the tests that read them, through make test/rust/conformance (the riverqueue library unit tests and protocol_fixtures) and make test/js/conformance (the two fixture test files, which run from source with no build). Cargo and pnpm are cached, so it should take a couple of minutes on one runner, and it adds no matrix entries.

conformance/ is its own module, like riverdriver/riverdrivertest, for two reasons. A nested go.mod keeps the generator and generated fixtures out of River's module zip, so users never download them. It's also a real module rather than a stub, so it can import River's internal packages through go.work. It's untagged and never released. A second commit adds make check/modzip, which runs in the submodule_check CI job. It uses golang.org/x/mod/zip to list the files each workspace module would publish and fails if any of them are testdata or fixtures paths, JSON files, or anything under conformance/, js/, or rust/.

The port commits also make sure test data can't ship in a package. Today the riverqueue crate publishes all of tests/, including the fixture JSON, because Cargo includes it by default. Every crate now has an include allowlist, so riverqueue goes from 107 packaged files to 75, and make check/rust/package fails if an archive contains a tests, fixtures, or testdata path or a JSON file. The npm packages already left test data out through their files lists, but nothing enforced it. The JavaScript package check now rejects packed testdata, fixture, or golden paths and any JSON other than package.json and the migrations manifest.

[brandur]

LGTM man! Should we merge this, or do you have it still set to draft because you're working on it?