fix(buffa): re-export serde_json so extension JSON deserialize compiles without a direct consumer dep

[iainmcgin]

Summary

Part 1/3 of the buf/validate/validate.proto build fix (alongside #114 and #115 — issue context in #113).

Buf reported that the bufbuild_registry_anthropics_buffa SDK (generated from the BSR with the buffa plugin, json=true) fails to build because the generated buf.validate.rs references ::serde_json::Value but the SDK's Cargo.toml doesn't declare serde_json.

The path comes from the hand-written Deserialize impl emitted for messages with extensions N to M; ranges (validate.proto declares 21 of them). It buffers "[pkg.ext]" JSON keys into a serde_json::Value before dispatching to extension_registry::deserialize_extension_key. Because the emitted path is a bare ::serde_json::Value, every consumer of json=true codegen silently picks up a hard requirement on a direct serde_json dep — a footgun the BSR plugin config (which only declares buffa, buffa-types, serde, bytes) walked into.

Fix

Re-export serde_json from buffa (gated on the json feature, #[doc(hidden)], matching the existing bytes re-export) and route the codegen path through ::buffa::serde_json::Value. After this change the generated SDK compiles with only buffa, buffa-types, and serde declared.

serde itself deliberately stays a direct consumer dep: the #[derive(::serde::Serialize)] macro emits extern crate serde as _serde; by default, which a re-export alone cannot satisfy without stamping #[serde(crate = "...")] onto every generated derive (and rewriting every other emitted ::serde:: path). That's feasible but out of scope here; the BSR plugin already declares serde.

No checked-in generated code changes — none of the WKTs declare extension ranges, so task gen-wkt-types is a no-op.

Reproduction

Minimal repro: a crate that runs buffa-build against buf/validate/validate.proto with .generate_json(true):

Before: 21 × error[E0433]: cannot find serde_json in the crate root
After: those errors are gone.

(There are also 15 × error[E0433]: cannot find field_descriptor_proto in protobuf from the same proto — that's a separate gap in the default .google.protobuf → ::buffa_types::google::protobuf extern_path mapping, which doesn't cover descriptor.proto types. Tracked in #113 and addressed by #114 + #115.)

Notes

• Added a codegen test asserting every ::serde_json:: occurrence is preceded by ::buffa:: (count-equality, so it catches turbofish/trait-bound contexts too).
• Documented the load-bearing #[doc(hidden)] pub use re-exports in CONTRIBUTING.md so a future cleanup pass doesn't remove them.
• Updated docs/guide.md to add serde to the example [dependencies] (it was always required but never shown) and clarify that serde_json is only needed by the consumer's own serde_json::to_string calls, not by generated code.
• protoc-gen-buffa/buf.plugin.yaml is still pinned to 0.3 and predates json=true — it's stale and should be bumped at release time, not here.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}