buffa-remote-derive: generate feature-gated serde/Arbitrary/reflection forwarders

#251 landed the `buffa-remote-derive` crate (`ProtoString`/`ProtoBytes`/`ProtoList`/`ProtoBox`/`MapStorage` derives for newtypes over remote types), scoped to the binary codec only. This issue tracks the remaining piece of #212's design sketch: optionally generating the feature-gated forwarders so a derived newtype is usable in JSON, fuzzing, and reflection builds without hand-written impls.

What the derives currently do **not** generate, and where the gap bites:

- **serde forwarders** — a string newtype used as a repeated element, an `optional` field, or a map value serializes through its own `Serialize`/`Deserialize`; without them a `generate_json(true)` build fails with a trait-bound error deep in generated message code. (Bytes newtypes are exempt: all bytes positions route through the base64 `with`-modules.) The crate docs' "Scope: the binary codec only" section documents the current hand-written workaround (`#[derive(serde::Serialize, serde::Deserialize)]` + `#[serde(transparent)]`).
- **`arbitrary::Arbitrary`** — needed for fuzz targets that construct messages containing the newtype.
- **reflection (`ReflectList`/`ReflectMap`)** — needed for vtable-reflection builds where the newtype backs a `repeated` or `map` field.

Design questions to settle before implementing:

- Feature flags on the derive crate (`json`/`arbitrary`/`reflect`) versus derive-attribute opt-ins (`#[buffa(serde)]`); a proc-macro crate's features are unified across the dependency graph, which argues for per-derive attributes.
- Whether the serde forwarder should be `#[serde(transparent)]`-equivalent (delegate to the remote type's serde) or route through `AsRef`/`From` like buffa's own with-modules, which would drop the remote-type-must-support-serde requirement.

Until then, the hand-written pattern in `examples/custom-types/src/types/` is the reference, and the per-position serde matrix lives in that example's README.