pxf: (pxf.default) on a repeated field throws ClassCastException out of the decoder

[trendvidia]

(pxf.default) on a repeated field throws a raw
java.lang.ClassCastException out of the decoder instead of a
PxfException. Same failure class as trendvidia/protowire-go#66.

Repro

message Config {
  repeated string tags = 6 [(pxf.default) = "ignored"];
}

Decode a document that leaves tags absent — FastDecoder.postDecode
reaches applyDefault only on the absent-field path — and the call
unwinds with:

java.lang.ClassCastException: class java.lang.String cannot be cast to
class java.util.List (java.lang.String and java.util.List are in module
java.base of loader 'bootstrap')

Mechanism

FastDecoder.applyDefault switches on fd.getJavaType():

switch (fd.getJavaType()) {
    case STRING  -> b.setField(fd, def);
    …
}

getJavaType() reports the element type and says nothing about
cardinality, so repeated string is STRING and a bare String reaches
Builder.setField. protobuf-java's setField requires a List for a
repeated field and casts unconditionally.

Verified with a probe on DynamicMessage.Builder over
org.protowire.pxf.testproto.AllTypes:

repeated_string javaType=STRING isRepeated=true
setField(repeated_string, "ignored") -> ClassCastException: String cannot be cast to List

Every scalar arm of the switch has the same shape, so the bug is not
string-specific — repeated int32, repeated bool and the rest all
reach setField with a boxed scalar.

(The probe file was removed; the tree is unmodified apart from the
pre-existing gradlew.bat modification, which I did not touch.)

Map fields are fine, but the message is confusing

map<string, string> has getJavaType() == MESSAGE, so it lands in
applyMessageDefault, misses every well-known-type branch, and throws a
proper PxfException — but one naming the synthetic entry type:

default values not supported for message type test.v1.AllTypes.StringMapEntry (field "string_map")

which describes protobuf's map representation rather than the mistake the
schema author made. protowire-go PR #67 replaces the equivalent message
with one naming the placement.

Suggested fix

Guard on cardinality before the getJavaType() dispatch, matching
protowire-go PR #67 and the message protowire-typescript already produces:

if (fd.isMapField()) {
    throw new PxfException(Position.UNKNOWN,
            "default values not supported for map field \"" + fd.getName() + "\"");
}
if (fd.isRepeated()) {
    throw new PxfException(Position.UNKNOWN,
            "default values not supported for repeated field \"" + fd.getName() + "\"");
}

Note isRepeated() is true for map fields too, so the map check must come
first.

Context

The spec says nothing about where (pxf.default) may be placed — that gap
is trendvidia/protowire#223, and whether the check should move to
bind time is trendvidia/protowire-go#68. This issue is narrower and needs
neither settled: whatever the placement rule turns out to be, a decoder
should not leak a ClassCastException from protobuf-java's reflection
layer to its caller.

Port	repeated + (pxf.default)
protowire-go (main)	panic in protoreflect.Message.Set
protowire-go (PR #67, open)	error: default values not supported for repeated field "tags"
protowire-rust	silently sets ["ignored"]; pb output changes
protowire-java	ClassCastException out of the decoder
protowire-typescript	error: default values not supported for list field "tags"

Related: trendvidia/protowire#223, trendvidia/protowire-go#66,
trendvidia/protowire-go#68, trendvidia/chameleon#131.

[trendvidia]

Spec update, and a sequencing note that splits this issue in two.

The rule is now normative. trendvidia/protowire#224 is merged: draft
-01 §annotation-extensions gained a "Default Placement" subsection
stating where (pxf.default) may be set, and requiring binding tools to
reject the rest.

But only half of it applies to this port today. The spec states the
constraint as a bind-time check, which protowire-go implements in its
schema walker (trendvidia/protowire-go#69). That half does not belong here
yet:

• This port is at 1.0.1. The bind-time placement family arrived with
  (pxf.key) in spec v1.2, and SchemaValidator here covers only the
  reserved-name rules — Kind is FIELD | ONEOF | ENUM_VALUE, and
  Violation is a four-component record with no detail field to carry a
  placement explanation. Nothing under pxf/src/main/java/ mentions
  pxf.key or 50002 at all. That is not a defect: STABILITY.md
  makes per-port adoption of v1.2 grammar independent, and pxf: quoted entry names + keyed repeated fields (protowire#116) #50 already
  tracks it.
• So the bind-time (pxf.default) check should ride along with pxf: quoted entry names + keyed repeated fields (protowire#116) #50, when
  SchemaValidator grows the annotation-placement family and Violation
  grows the detail component. Both placement checks want the same record
  change, so doing them together avoids reshaping a public record twice.

What stays in this issue is the runtime bug, and it should not wait
for any of that: a raw ClassCastException escaping the decoder is wrong
under every revision of the spec, including the v1.0 text this port
targets. The guard from the original report is still the fix, with the map
check first because isRepeated() is true for map fields too:

if (fd.isMapField()) {
    throw new PxfException(Position.UNKNOWN,
            "default values not supported for map field \"" + fd.getName() + "\"");
}
if (fd.isRepeated()) {
    throw new PxfException(Position.UNKNOWN,
            "default values not supported for repeated field \"" + fd.getName() + "\"");
}

That also replaces the map-field message that currently names the
synthetic …Entry type — the same confusing diagnostic protowire-go
replaced in its own #67.

Worth reading the merged §"Default Placement" before implementing, since
it fixes the honorable message-type set: Timestamp, Duration, the nine
*Value wrappers, pxf.BigInt, pxf.Decimal, pxf.BigFloat — and
nothing else, groups included.