docs: say which conformance messages the table run does not exercise

The via-table paragraph names the categories that fall back to the unrolled
codec, including the top-level TestAllTypesProto2, and gives the measured
success count. The text failure list notes that the table run shares it.

Author: iainmcgin

CONTRIBUTING.md

@@ -92,7 +92,7 @@ Requires cmake, a C++ toolchain, and protoc v30+ on PATH or `$PROTOC`
 (std, no_std, via-view, via-lazy, view-json, via-reflect, via-vtable, via-table), each
 producing two suites:
 
-1. Binary + JSON suite — expects thousands of successes (~5500 std, ~5500 no_std, ~5500 table). The via-view and via-lazy runs only handle binary→binary (~2800); the view-json, via-reflect, and via-vtable runs handle binary→JSON (and via-reflect also binary→binary).
+1. Binary + JSON suite — expects thousands of successes (~5500 std and no_std; 5,549 table). The via-view and via-lazy runs only handle binary→binary (~2800); the view-json, via-reflect, and via-vtable runs handle binary→JSON (and via-reflect also binary→binary).
 2. Text format suite — 883 successes for std, no_std and table (the full suite); via-view, via-lazy, view-json, via-reflect, and via-vtable show `0 successes, 883 skipped` (those modes have no `TextFormat` path).
 
 So a healthy run shows **16 `CONFORMANCE SUITE PASSED` lines**.
@@ -104,7 +104,8 @@ The Dockerfile builds **three binaries**: one with default features (std), one w
 - **view-json** (`BUFFA_VIEW_JSON=1`) — binary→JSON through `decode_view → serde_json::to_string(&view)`, verifying the generated view `Serialize` impls (and the hand-written WKT view `Serialize` impls in `buffa-types`).
 - **via-reflect** (`BUFFA_VIA_REFLECT=1`) — binary/JSON I/O through `DynamicMessage`'s descriptor-driven codec and reflective serde, verifying the runtime reflection codec independently of any generated type.
 - **via-vtable** (`BUFFA_VIA_VTABLE=1`) — binary→JSON: decode the view, walk its vtable `ReflectMessage` surface to rebuild a `DynamicMessage`, then serialize to JSON. Verifies the generated `impl ReflectMessage for FooView`. It reuses `DynamicMessage`'s JSON serializer (which passes the corpus cleanly under via-reflect), so any failure isolates a bug in the vtable `get`/`has`/`for_each_set` surface. Requires the conformance crate's `reflect` feature, so it is absent from the no_std binary.
-- **via-table** (the `table` binary, no env var) — the whole std run, binary, JSON and text, against test messages generated with `CodecStrategy::Table`, so the table codec's decode, size and encode paths, oneofs, maps and the bridge to well-known-type children see the corpus. The messages the table cannot handle stay unrolled inside it: the proto2 groups and their field types, `MessageSet`, and the two `TestAllTypesProto2` messages that have extension ranges under JSON. `build.rs` prints which messages fell back, and `table_messages_use_the_table` in `conformance/src/main.rs` fails the build if the messages that must use the table stop doing so. The build needs Rust 1.77, which `buffa-build` enforces, so the default conformance build keeps the 1.75 MSRV.
+
+**via-table** is a separate binary, built with `--features table` (no env var), that runs the whole std run — binary, JSON and text — against test messages generated with `CodecStrategy::Table`. It exercises the table codec's decode, size and encode paths, oneofs, maps and the bridge to well-known-type children on the proto3, editions and nested proto2 messages. The messages the table cannot handle run through the unrolled codec instead: messages with extension ranges under JSON, `MessageSet` messages, group types and the messages that hold them. That includes the top-level `TestAllTypesProto2`, which via-table therefore does not exercise on the table. `buffa-build` prints a `cargo:warning` naming the messages that fell back, and a compile-time check in `conformance/src/main.rs` fails the build if the messages that must use the table stop doing so. The `table` feature needs Rust 1.77; `conformance/Cargo.toml` says why.
 
 **Expected failures** are listed in `conformance/known_failures.txt` (std binary+JSON), `conformance/known_failures_nostd.txt` (no_std binary+JSON), `conformance/known_failures_view.txt` (via-view), `conformance/known_failures_lazy.txt` (via-lazy), `conformance/known_failures_view_json.txt` (view-json), `conformance/known_failures_reflect.txt` (via-reflect), `conformance/known_failures_view_vtable.txt` (via-vtable), `conformance/known_failures_table.txt` (via-table; currently empty), and `conformance/known_failures_text.txt` (text format — shared between std, no_std and table; currently empty). The text list is passed via `--text_format_failure_list` since the runner validates each suite's list independently. When a previously-failing test starts passing, remove it from the relevant file; when a new test is expected to fail, add it.
 

conformance/known_failures_table.txt

@@ -3,3 +3,7 @@
 # Tests listed here are expected to fail in the via-table run and will not
 # cause it to report a failure.  Each line is a test name (matched by the
 # runner with --failure_list).  Remove entries as failures are fixed.
+#
+# The messages the table cannot handle run through the unrolled codec in this
+# run, including the top-level TestAllTypesProto2, so its tests do not exercise
+# the table.

conformance/known_failures_text.txt

@@ -4,4 +4,5 @@
 # The text-format suite runs separately from the binary+JSON suite and
 # validates this list independently.  Remove entries as failures are fixed.
 #
-# std and no_std share this file — textproto has no std-only paths.
+# All text-format runs (std, no_std, table) share this file — textproto has
+# no std-only paths.