Bump buffa 0.6 → 0.7 (and connectrpc 0.6 → 0.7)

[sachaw]

buffa 0.6 → 0.7 (and connectrpc 0.6 → 0.7)

buffa 0.7 is out; the ^0.6 pins exclude it, so downstreams on buffa 0.7
can't use this crate. Two commits:

1. Dependency bump (no API delta)

Bumps every pin — buffa, buffa-build, buffa-codegen 0.6→0.7, and the
optional connectrpc 0.6→0.7. The runtime, protos, codegen plugin, and
conformance crate all compile unchanged against the 0.7 line. Conformance is
preserved:

PASS (failed: 0, skipped: 0, passed: 2872, total: 2872)

(proto2, proto3, editions 2023 — built with protoc 35.1.)

2. #[connect_impl] for the 0.7 handler shape

connectrpc 0.7 hands handlers a ServiceRequest<'_, T> instead of an
OwnedView<_>. The macro matched only OwnedView, so under 0.7 it would
match no parameter and silently no-op — a validation bypass worse than a
compile error. Both types expose to_owned_message(), so the inserted
decode+validate is unchanged; only the type-name match widens to accept
ServiceRequest. A ServiceRequest test is added alongside the existing
OwnedView one.

[varunshahdev]

+1 on getting this merged. We're a downstream on buffa/connectrpc 0.7 and the ^0.6 pins currently block adoption entirely.

The #[connect_impl] fix is the important part here, not just the version bump. Our generated handlers take ServiceRequest<'_, T> under connectrpc 0.7, so with the old macro the validation would have silently no-op'd — a bypass rather than a compile error, exactly as the PR description notes. Widening the match to accept ServiceRequest (both types expose to_owned_message()) is the correct fix, and the added ServiceRequest test covers it.

Conformance staying at 2872/2872 with no API delta on the runtime/codegen side matches what we'd expect from a 0.6→0.7 bump. Would be great to see this reviewed/merged — happy to help test against a real 0.7 codebase if useful.

[jrandolf]

Fixed in #17.