feat: add mcpplibs.grpc 1.83.0 (Form A, grpc-m)

[Sunrisepeak]

The end of the gRPC track that #147 (abseil, protobuf), #148 (re2, the protobuf upb
feature) and #149 (c-ares) built toward. gRPC itself lands as a Form A descriptor
pointing at mcpplibs/grpc-m.

Why this one cannot be a compat descriptor

Every other heavy library here points at an upstream tarball. gRPC publishes none:

v1.83.0 release assets	none at all
tag archive third_party/abseil-cpp	1 entry (empty submodule placeholder)
…protobuf / re2 / boringssl-with-bazel / zlib	1 entry each

So there is nothing for url + sha256 to address. grpc-m's release tarball is that
artifact: upstream's src/ and include/ vendored with zero patches, plus the two
third_party pieces gRPC really ships (address_sorting, xxhash).

What it does not vendor is why it belongs on this index rather than standing alone:
abseil, protobuf(+upb), re2, c-ares, OpenSSL and zlib all come from the packages here,
so a consumer that also uses protobuf or abseil directly links one copy instead of
colliding with a second vendored set.

No CMake, no Bazel, no configure — checked, not assumed

gRPC's tree contains no .h.in or config.h.cmake, and its generated upb code is
checked in upstream, so mcpp needs only include paths. All 1001 TUs are compiled by
the resolved toolchain, so nothing inherits a foreign C++ ABI the way an
install()-driven CMake build would — which is exactly what ruled that route out for
gRPC (.agents/docs/2026-08-04-grpc-feasibility-analysis.md §2.1).

The source list is upstream's own — the union of add_library(gpr), grpc, grpc++
and address_sorting — and grpc-m's tools/gen_sources.py --check runs in that repo's CI
to prove the manifest has not drifted from the vendored tree. One file is excluded:
src/core/ext/upb-gen/google/protobuf/descriptor.upb_minitable.c, byte-for-byte
identical to the bootstrap copy compat.protobuf's upb feature compiles.

linux + macOS only

The reason is a dependency, not gRPC: compat.openssl has no windows xpm entry, so
resolution there fails with E_NOT_FOUND before anything compiles, and gRPC's secure
build cannot drop TLS. The member is gated the way tests/examples/openssl already is —
cfg-gated dependency, no-op main() on windows. #150 is the fix for the underlying
gap, and grpc-m already carries its windows flags for the day it lands.

The member

It drives import grpc; only and carries no protoc output: gRPC's codegen needs host
tools mcpp cannot hand a consumer (mcpp::dep_dir() gives a package's source dir, and
kind = "bin" targets are not exposed), so grpc-m's own examples/helloworld covers the
generated-stub path while this member covers the module surface. It asserts the error path
too — a Status that is not ok — so an always-OK stub could not pass.

Verification

Pinned mcpp 2026.8.3.3, gcc@16.1.0, MCPP_BUILD_CACHE=local, target/ and .mcpp/
removed first. The package downloads from the descriptor's real release tarball and sha:

Compiling mcpplibs.grpc v1.83.0
grpc::Version() = 1.83.0
grpc module: OK
test result ok. 1 passed; 0 failed; finished in 247.85s

grpc-m's own CI is green on both platforms for the tagged commit (linux 54m21s, macOS
29m49s), where examples/helloworld stands a real server on a loopback port and makes a
real unary RPC — including the error path, which crosses the wire as INVALID_ARGUMENT.

CN mirror published and closed-loop checked: mcpp-res/grpc@1.83.0 returns http=200 and
is byte-identical to GLOBAL.

Full write-up: .agents/docs/2026-08-05-add-grpc-plan.md.