Add anthropics/connect-rust plugin v0.3.2

[iainmcgin]

Adds the protoc-gen-connect-rust plugin for ConnectRPC Rust service bindings, under the new top-level anthropics org as requested in earlier review.

About connect-rust

connect-rust is a Tower-based Rust implementation of the ConnectRPC protocol:

• Three protocols: Connect, gRPC, gRPC-Web - same service impl handles all three
• Full conformance: 3600 server tests, 2580/1454/2838 client tests across Connect/gRPC/gRPC-Web
• Zero-copy request handling via buffa view types - request.name is a &str borrow into the decoded buffer
• Tower integration: composes with axum, hyper, tower middleware

Crates on crates.io: connectrpc, connectrpc-codegen, connectrpc-build.

Plugin layering

The plugin emits service stubs only - server traits, typed clients, monomorphic dispatchers. Message types come from buf.build/anthropics/buffa (declared in deps:). Generated stubs reference message types via absolute Rust paths (crate::<buffa_sdk>::pkg::Type).

Dockerfile note: the protoc-gen-connect-rust binary is a [[bin]] target inside the connectrpc-codegen crate, so cargo install connectrpc-codegen is what produces it.

Open question: extern_path injection

The plugin needs to know where the buffa SDK crate lives to emit the right paths. It accepts either extern_path=.=<rust_path> (same format as tonic/prost) or the shorthand buffa_module=<rust_path>.

I left opts: [] with a comment in the yaml because I assume BSR injects extern_path=.=::<buffa_sdk_crate_name> at invocation time based on the deps: config - same as it does for tonic referencing prost types. Would appreciate confirmation of the exact value BSR injects so I can verify the plugin handles it correctly.

Dependencies

Depends on the buffa plugin landing first: #2333

Process note

CONTRIBUTING.md asks for an issue first - happy to open one if you would prefer to discuss before reviewing. Filed as draft.

[bufdev]

#2333 (comment)

[iainmcgin]

changed to crate ref instead of github ref 👍

[stefanvanburen]

should be fine to leave this empty, and the BSR will figure out extern_path settings using the prost syntax 👍.

[stefanvanburen]

silly non-expert-in-rust question: I see the default features; those don't include the tls feature, but is that just something that is "enabled" by having the various "deps" in the sub-features installed? (Mostly trying to confirm that someone consuming this generated SDK could still use the TLS features.)

[iainmcgin]

[claude code] Yes — Cargo features are additive and unified per-crate across the dependency graph. The generated SDK crate only needs connectrpc's default features for the generated code to compile, so that's all it declares. A consumer who wants TLS adds their own direct dependency in their application's Cargo.toml:

connectrpc = { version = "0.4", features = ["tls"] }

Cargo then compiles connectrpc once with the union of features requested by both the SDK crate and the application, so tls (and client-tls / server-tls / any other optional feature) is fully available. Same model the tonic SDK crates use — the SDK doesn't gate runtime features.