Retain and expose unrecognized schema-root properties, alongside existing field-level annotation retention

[jfallows]

Describe the desired outcome from the user's perspective

As a Zilla operator, I want a catalog implementation to be able to attach a single fragment of metadata to a schema as a whole — distinct from tagging any individual field — so that metadata scoped to the entire schema isn't forced into a per-field shape it doesn't fit.

Acceptance criteria

1. Root-level (schema-root) annotation access

A peer mechanism to #2302's field-level annotation retention, not a broadening of it. #2302 retains and exposes unrecognized field annotations (AvroField.attribute(name) and peers); this issue does the same at the schema root.

• Add JsonValue attribute(String name) at the schema-root level for each format (AvroSchema, JsonSchema, ProtobufSchema — mirroring Retain and expose schema field annotations from Avro, JSON Schema, and Protobuf codecs #2302's per-format field-level attribute(String)), returning null when absent
• No inheritance to fields — a root-level annotation is never consulted when matching a field-level tagged: matcher, and a field-level annotation is never visible through this accessor
• Requires retaining unrecognised schema-root properties in each format's compiler, parallel to Retain and expose schema field annotations from Avro, JSON Schema, and Protobuf codecs #2302's per-field retention, at the root instead

2. Where this matters: a catalog resolving something schema-wide

A catalog's resolve(schemaId): String implementation is the natural place to attach schema-wide metadata that a registry returns as a sibling of the schema text rather than embedded within it — fetch both in the one round trip, and synthesize a schema text carrying the extra property at the schema root before returning it. An ordinary, unaware caller parsing the same text is unaffected, since a JSON schema format already tolerates unrecognized top-level properties.

3. Coverage

• round-trip: a schema declaring a root-level property of each JSON shape (scalar, array, object) compiles, exposes it via attribute(name), and survives the existing conformance suites, for each of the three formats
• a root-level property never satisfies a field-level tagged: matcher, and a field-level annotation is never visible through the root accessor
• absent property returns null, not an exception

Additional context

Companion to #2302, same retention mechanism at a different scope.

[ReguiguiMohamed]

Hi @jfallows , i love the work and repo and i'd like to contribute!
I have a local implementation ready for this issue. Before opening the PR, could you clarify two Protobuf details?

1. should the root accessor mirror ProtobufField.option(String) and return ProtobufConstant, or literally be attribute(String) returning JsonValue?
2. Protobuf option constants have no array syntax. Should Protobuf coverage be limited to scalar and message-valued options, or should this issue introduce a ListValue representation?
   i’ll open the PR once i can confirm these points, thank you !