[jbuehler23]

Objective

Part of #23013. Follow-up to #26308.

Types that register ReflectSerialize are sent over BRP in their own serde format, but registry.schema still describes their reflected fields. Vec3 is described as {x, y, z} and sent as [x, y, z], Name as a newtype and sent as a string, and so on, so tools building values from the schema get them wrong.

Solution

• a BrpJsonSchema trait and #[reflect(BrpJsonSchema)] type data, so a type can declare the JSON schema of its serialized form
• built-in schemas for the glam types, Duration, Entity, Name, the NonZero integers, Uuid, AssetPath and a few string-like types; glam array items are titled (x, y, x_axis.y, ...)
• for declared types the top-level schema describes the wire format, and the reflected structure moves to a new reflectSchema field
• opaque types with custom serde and no declared schema get rawJson: true instead of a guessed shape
• SchemaRegistry keeps reading the reflected structure, so Vec3 still has x, y and z fields, and TypeSchema::wire gives the wire schema

"glam::Vec3": {
  "kind": "Struct",
  "type": "array",
  "prefixItems": [
    { "$ref": "#/f32", "title": "x" },
    { "$ref": "#/f32", "title": "y" },
    { "$ref": "#/f32", "title": "z" }
  ],
  "minItems": 3,
  "maxItems": 3,
  "reflectSchema": { "type": "object", "properties": { "x": ..., "y": ..., "z": ... } }
}

Structured types with derived serde, like Transform, are unchanged since their serialized form already matches their fields.

Testing

Each built-in is checked against a real serialized value, and glam item titles are checked against the reflected fields. Other tests cover a user-declared schema, rawJson, and the index.

AI disclosure

The implementation and tests were written with the help of AI, and I reviewed the changes before using any of the proposed code.

[alice-i-cecile]

This feels super janky to me. Why do we have / want special-cased logic for glam inside of bevy_remote, rather than deriving this from reflection data or something? This feels contrary to both the point of this PR and like it ignores the annotation work done earlier.

[alice-i-cecile]

Very skeptical of impl_brp_json_schemas. Embedding this sort of random list into bevy_remote is 100% going to bite us. We need to find a better architecture to solve this problem.

[jbuehler23]

Yeah, fair. The list is there because Vec3 reflects as x, y, z but serializes as [x, y, z], and reflection has no way to express that difference. We could use bevy_annotations for this: something like @SerializeAsSeq on glam's reflect impls, plus one for types that serialize as strings, and bevy_remote builds the schema from those, no list.

Catch is bevy_annotations depends on bevy_reflect, where the glam impls live. I'd flip that: annotations become plain types and bevy_reflect implements Reflect for them behind a feature, like it does for glam. Does that sound ok @alice-i-cecile?