feat: add compat.abseil 20250512.1 + compat.protobuf 35.1

[Sunrisepeak]

Groundwork for gRPC: its two largest prerequisites, added as ordinary compat packages.

Why these two don't need a dedicated repo (and gRPC does)

The starting question was whether gRPC could be added as compat.grpc.lua. The analysis
(.agents/docs/2026-08-04-grpc-feasibility-analysis.md) says no — but it also found that
abseil and protobuf are a completely different case:

	abseil / protobuf	gRPC
self-contained release asset	✅ abseil-cpp-20250512.1.tar.gz 2.2MB · protobuf-35.1.tar.gz 7.1MB	❌ no release assets at all; the tag archive has abseil/protobuf/re2/boringssl/zlib as empty submodule placeholders (1 entry each)
configure step	❌ none — platform handling is in-source #ifdef	needs per-OS config
protoc bootstrap	❌ none — the 14 .pb.cc (well-known types + descriptor.pb.cc) are checked in	plugins must be built

So these two land in the standard Shape A template, while gRPC still needs the grpc-m
adaptation-repo route (opencv-m precedent). That plan is recorded in the analysis doc.

Versions track upstream verbatim — a correctness requirement here

20250512.1 is the Abseil LTS tag. protobuf 35.1's MODULE.bazel names that same LTS,
and gRPC 1.83.0 pins protobuf at commit 35cd01f (== tag v35.1) and abseil at 76bb243
("Abseil LTS Branch, May 2025, Patch 1" == 20250512.1). Keeping the upstream spelling is
what lets a future gRPC package link one abseil instead of colliding with a second
vendored copy.

Source lists

• protobuf transcribes libprotobuf_srcs from upstream's own src/file_lists.cmake
  (79 TUs). A directory glob cannot substitute: src/google/protobuf/**/*.cc would also
  sweep in libprotoc (157 more TUs) and the tests, while two runtime TUs live under
  compiler/ (importer.cc, parser.cc — the .proto text parser is part of the
  runtime), so nothing separates the two libraries by directory.
• abseil globs absl/**/*.cc and trims by upstream's own test/benchmark naming
  conventions plus 14 named stragglers. Four excluded TUs define their own main() — a
  dependency's objects all enter the consumer's link, so any one would collide with the
  consumer's main() and break every dependent build.

compat.protobuf depends on compat.abseil (protobuf's public headers include absl/…)
and gates Gzip streams behind a gzip feature — io/gzip_stream.cc is wrapped head-to-toe
in #if HAVE_ZLIB, so the default build compiles it to an empty TU and pulls no zlib at all.

Verification

Cold, with the CI configuration (pinned mcpp 2026.8.3.3, gcc@16.1.0,
MCPP_INDEX_MIRROR=GLOBAL, MCPP_BUILD_CACHE=local), target/ + .mcpp/ removed first:

::: abseil :::         Compiling compat.abseil v20250512.1   test result ok. 1 passed; 0 failed  (18.57s)
::: protobuf :::       Compiling compat.protobuf v35.1       test result ok. 1 passed; 0 failed  (63.35s)
::: protobuf-gzip :::  Compiling compat.protobuf v35.1       test result ok. 1 passed; 0 failed  (54.48s)

• Object counts checked, not assumed: 151 .o linked for compat.abseil, 80 for compat.protobuf.
• The protobuf test uses no protoc output anywhere: .proto text through the runtime's own
  parser → DynamicMessage → wire/TextFormat/JSON round-trips → well-known types → UTF-8
  validation (reaching utf8_range.c). A truncated payload must be rejected, so a no-op parser
  cannot pass.
• gzip verified negatively too: reverting the member to a bare protobuf = "35.1" fails
  the link with undefined GzipOutputStream/GzipInputStream symbols.
• CN mirrors closed-loop checked: mcpp-res/abseil@20250512.1 and mcpp-res/protobuf@35.1
  both return http=200 and are byte-identical to GLOBAL.
• Lint: all 70 descriptors pass syntax / mirror / name checks, cross-package refs OK, and both
  new descriptors pass mcpp xpkg parse on the pinned mcpp.

Two known mcpp-side issues (documented, neither affects CI)

1. randen_round_keys.cc prints a false module 'binascii' imported but not provided warning —
   the Python generator pasted inside a /* … */ block comment starts with import binascii at
   column 0, and mcpp's text scan strips // comments and raw strings but not block comments.
   It cannot be silenced from the descriptor: scan_overrides rejects an entry that declares
   neither provides nor imports, which is exactly this file's true answer.
2. A new instance of [bug] 全局 build cache:obj 布局随消费方包组合变化(#233 消歧),而 cache key 不含消费方 → 同一 key 下第二个消费者必挂 'missing and no known rule' mcpp-community/mcpp#344 — abseil's str_format/parser.cc and protobuf's
   compiler/parser.cc share a basename, and the package build cache key doesn't cover the
   collision context. CI is unaffected (it already sets MCPP_BUILD_CACHE: local for this
   very reason), and upstream fixed it in 2026.8.3.4, so MCPP_VERSION is deliberately left alone.

Both are written up in .agents/docs/2026-08-04-add-abseil-and-protobuf-plan.md.