Fixed fuzz

AGENTS.md

@@ -115,6 +115,15 @@ cargo deny check
 python3 scripts/check_doc_links.py
 ```
 
+`fuzz/` is a standalone workspace, so no gate above compiles it, and a fuzz
+target that builds a library type by hand goes stale the moment that struct
+gains a field. When a change adds or reshapes a type or function a target
+constructs or calls, build the targets too:
+
+```bash
+cd fuzz && cargo fuzz build --target x86_64-unknown-linux-gnu
+```
+
 When a query or migration is added or changed, regenerate and commit the
 offline cache. CI runs `cargo sqlx prepare --check --workspace` and fails if
 the committed cache is stale; regenerate it with the plain form:

README.md

@@ -218,6 +218,13 @@ cargo deny check
 python3 scripts/check_doc_links.py
 ```
 
+CI also builds the fuzz targets, which none of the gates above compile. Run it
+when a change adds or reshapes a type or function a target constructs:
+
+```bash
+cd fuzz && cargo fuzz build --target x86_64-unknown-linux-gnu
+```
+
 ## Container
 
 Build both architectures with the bake definition, then run the image. The

docs/CONTRIBUTING.md

@@ -49,7 +49,9 @@ cargo sqlx prepare --workspace           # regenerate the cache
 Run all of these before opening a change. CI runs this set plus additional
 gates: `cargo sqlx prepare --check --workspace`, the fuzz targets
 (`cargo fuzz build`), coverage, `cargo mutants`, `miri`, and the separate
-`.github/workflows/docs.yml` link check.
+`.github/workflows/docs.yml` link check. Nothing in the set below compiles
+`fuzz/`, so build the targets yourself when a change reshapes a type or
+function one of them uses (see [Fuzzing](#fuzzing)).
 
 ```bash
 cargo fmt --check

fuzz/fuzz_targets/jar_claims.rs

@@ -62,6 +62,7 @@ fn client_with_method(method: &str) -> Client {
     contacts: None,
     software_id: None,
     dpop_bound_access_tokens: false,
+    access_token_format: "opaque".to_owned(),
     active: true,
     created_at: time::OffsetDateTime::UNIX_EPOCH,
     updated_at: time::OffsetDateTime::UNIX_EPOCH,