Follow-ups from #74: bytes_fields for map values, checked_add in bytes_from_source

[iainmcgin]

Tracking the items deferred from #74 (zero-copy Bytes in view→owned via slice_ref).

• bytes_fields for map<K, bytes> values. map_to_owned_expr in buffa-codegen/src/view.rs hard-codes v.to_vec() for TYPE_BYTES map values, so they're always Vec<u8> on the owned side regardless of bytes_fields config — and consequently never slice_ref'd in to_owned_from_source. The owned-side map type generation has the same gap (basic.proto's BytesContexts.by_key pins the current behavior). Wiring field_uses_bytes / bytes_to_owned through both sides would close the parity gap with singular/repeated/oneof.

• checked_add in bytes_from_source. The pointer-range containment check in buffa/src/view.rs uses wrapping_add to compute the end pointers. A wraparound could in theory let an out-of-range slice past the check into slice_ref (which would then panic on its own check). Can't happen on real targets (kernel reserves high addresses), but checked_add with a None → fall-back-to-copy is two extra lines and provably correct.

• Route bytes_fields-gated codegen through ::buffa::bytes::. → codegen: route bytes_fields paths through ::buffa::bytes:: re-export #77. 12 pre-existing sites emitted ::bytes::Bytes directly (all gated on bytes_fields, so never broke anyone in practice): impl_message.rs:877,1465,1576,1967,2246; impl_text.rs:605,688,841; message.rs:984,1092; oneof.rs:116; view.rs:61. Mechanical s/::bytes::Bytes/::buffa::bytes::Bytes/ plus WKT regen. The unconditional case (the to_owned_from_source signature) was fixed in view: zero-copy Bytes in to_owned via slice_ref of source buffer #74.

• Shared-buffer strings (string_fields). Mentioned in AnyView::to_owned_message copies Bytes payload unnecessarily #52's scope: a bytes::Bytes-backed string type (or Arc<str>) for owned string fields, so to_owned_from_source could slice_ref those too. Larger design question (UTF-8 validation, which wrapper type) — likely its own issue if/when there's demand.