[bfrancojr]

Pxf.marshal and Pb.marshal now refuse a message nested more deeply than MaxNestingDepth (default 100), instead of writing text or bytes that a reader at the same limit refuses. A reference cycle in a Pb struct now gets this error instead of overflowing the stack.

Fixes #167

What changes

• Pxf.marshal counts each { and [ it writes, the way a decoder of the text counts them. A list of messages is therefore two levels per element, and a map with message values is two per entry. This matches protowire-go's encoder, and the message is Go's: pxf: nesting depth exceeds MaxNestingDepth=100.
• An Any whose body would go past the limit is still written, as type_url and value, which any reader can read.
• Pb.marshal counts each submessage and map entry, as Go's pb.MarshalOptions does.
• The limit is per call: MarshalOptions.withMaxNestingDepth in pxf, and a new org.protowire.pb.MarshalOptions with Pb.marshal(Object, MarshalOptions). The old five-argument MarshalOptions constructor still exists, so existing callers compile.
• check-decode --format pb-render used protobuf-java's default recursion limit of 100. So the corpus's 101-level rows were refused by the stock reader before the producer ran, and they passed without testing anything. It now reads up to 10000 levels.

Classification: reversible by a revert. It adds API (two option methods and one record), which HARDENING.md asks for ("the limit is configurable per call"). Measured. Live: the corpus rows exercise it.

Evidence

• ./gradlew build at 0e979c9: 664 tests, 0 failures, 5 skipped. The 5 are pb: null and zero big numbers in Pb.marshal differ from protowire-go, and a null list element throws #159's disabled pb tests, which pb: write null and zero big numbers as protowire-go does, and a BigFloat normalised #170 enables.
• New pxf MarshalDepthTest (5 tests): 100 levels are written and read back, 101 are refused, for submessages, map values and lists. The per-call limit works up and down. An Any body past the limit stays raw.
• New pb MarshalDepthTest (4 tests): submessages, map entries, a cycle, and the per-call limit.
• The harness, run directly on the four corpus rows:
  • Before (main): deep-submessage-101 → reject: Protocol message had too many levels of nesting. That is the stock reader, not the producer.
  • After: deep-submessage-100 exit 0, deep-submessage-101 exit 1 pxf: nesting depth exceeds MaxNestingDepth=100, deep-map-100 exit 0, deep-map-101 exit 1 with the same message.
• Security gate with java removed from those two rows' skip (corpus: run java on the producer depth rows protowire#538): "Ran 213 (port, corpus) pairs across 3 ports. ✓ All ports conform". That is main's 211 plus the 2 java rows.

Merge order

This PR first, then trendvidia/protowire#538. It edits the corpus manifest, and the spec's security workflow builds Java from main.

Not covered here

The lite tier already passes these rows. Its PB producer, LiteWireWriter, is bounded by the PXF parser's limit. But a well-known-type literal (ts = 2024-01-01T00:00:00Z) is zero PXF levels and one PB level, so a document 100 levels deep with a literal at the bottom writes PB 101 levels deep. That is a question for the spec, not this port, so I filed it as trendvidia/protowire#537.

Conflicts

This conflicts lightly with #170, which also edits Pb.marshalScalar. Whichever merges second needs a rebase. I'll do it.

[bfrancojr]

CI passed on 0e979c9, the PR head read back from the remote: Build + Test, Conformance (Go reference), Analyze and CodeQL.