Make generated client feature gate configurable

[Jaksenc]

Problem

protoc-gen-connect-rust can already gate generated client items behind a Cargo feature, but the feature name is fixed to client. Crates that expose their generated client surface under a different feature name cannot use the existing gate directly.

Change

• Add Options::client_feature_name, defaulting to client, and thread it into generated client cfg attributes.
• Accept gate_client_feature=<name> in the protoc plugin while preserving the existing bare gate_client_feature behavior.
• Add connectrpc_build::Config::client_feature_name(...) as the build wrapper companion API.
• Reject empty custom feature names and keep the generated cfg as a string literal so names like grpc-client work.
• Document the additive option in the changelog.

This keeps the existing opt-in shape intact: gate_client_feature still enables gating, and the default gate remains client.

Validation

Using protoc v33.5:

• cargo test -p connectrpc-codegen gate_client_feature
• cargo test -p connectrpc-build gate_client_feature
• cargo check -p connectrpc-codegen
• cargo check -p connectrpc-build
• cargo check --workspace --all-features --all-targets
• cargo test --workspace --all-features
• cargo clippy --workspace --all-features --all-targets -- -D warnings
• cargo +nightly-2026-02-27 fmt --all -- --check
• RUSTDOCFLAGS="-Dwarnings" cargo doc --workspace --all-features --no-deps
• git diff --check

Risk

Low. This is additive, the default remains client, and the existing bare plugin flag continues to work. The main compatibility risk is rejecting an empty explicitly configured feature name; that is covered by a focused parser test.

Out of scope

• JSON or message-type feature gating.
• Regenerating checked-in generated code; default output is unchanged.
• Replacing or changing the existing gate_client_feature(bool) API.

Issue linkage

Closes #181

[github-actions]

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

[iainmcgin]

[claude code] Thanks — this is a clean implementation of #181 and the default behaviour is fully backward-compatible (task generate:all produces zero diff in the checked-in *.__connect.rs files).

I pushed two maintainer commits:

• 92d384b — merged main and resolved the CHANGELOG.md conflict (keep-both; also added the missing [#181] link reference).
• 3390690 — three small tightenings:
  • Validate the feature name against Cargo's grammar. A name like "grpc client" or "foo/bar" would emit #[cfg(feature = "...")] that Cargo can never enable, silently suppressing every generated client item with no diagnostic. The check is inlined for now; once the workspace moves to buffa-codegen 0.8 it can defer to buffa_codegen::FeatureGateNames::is_valid_name.
  • Config::client_feature_name(..) now also enables gate_client_feature, mirroring the plugin's gate_client_feature=<name> form. Previously calling only .client_feature_name("x") was a silent no-op (gating stayed off). The order-dependence with an explicit .gate_client_feature(false) is documented on both setters.
  • Updated gate_client_feature's rustdoc to cross-link the new setter instead of hard-coding "client".

LGTM with those applied.