feat: TeleportToRequest.realm — a teleport can name the realm its parcel is in

[robtfm]

What

TeleportToRequest gains optional string realm = 2: the realm the parcel belongs to (a world name such as foo.dcl.eth, or a realm url). When set, the client changes realm, a full reconnect as for ChangeRealm, even to the realm the player is already in, and then lands on the parcel there. Omitted, the request means what it always did.

Why

Parcel coordinates only address one realm's grid. A client feature that offers "a place" (a Places listing, a map pin) has a realm and a parcel, and today has to fire changeRealm and teleportTo as two independent requests. changeRealm resolves as soon as the change is accepted, not when the new realm is live, so a teleport issued after it resolves against the realm being left. From inside a World, jumping into a Genesis City place teleports to those coordinates within the World.

Carrying the realm on the teleport lets the client sequence the two correctly: change realm, then land on the parcel once the new realm is live.

Cherry-picked from experimental-bevy, where bevy-explorer implements it. Additive; clients that ignore the field behave as before.

[github-actions]

Test this pull request

• The @dcl/protocol package can be tested in scenes by running

  npm install "https://sdk-team-cdn.decentraland.org/@dcl/protocol/branch//dcl-protocol-1.0.0-33676973640.commit-0c3d984.tgz"

[robtfm]

On the red "Validate compatibility with main branch" check: it flags world_coordinates moving "from outside to inside a oneof" because proto3 optional puts the field in a synthetic oneof in the descriptor. For a message-typed field that changes nothing on the wire or in JSON. Message fields already have explicit presence in proto3: set → written as tag 1, length-delimited; unset → omitted. Before and after this change a serializer produces byte-identical output, and the generated TypeScript only widens (worldCoordinates: Vector2 | undefined → worldCoordinates?: Vector2 | undefined). (For a scalar field optional would change presence semantics, which is what the rule is really guarding.)

So against main, which has neither field, the whole change is additive:

• an older scene always sets world_coordinates, and a newer client reads it exactly as before; realm is simply absent.
• a newer scene that sets a parcel sends the bytes older clients already parse; one that sets only realm sends an unknown field 2 (skipped) and no field 1, which decodes fine and degrades to that client's handling of a parcel-less teleport.

The flag itself is a tooling artifact of the pinned buf version. With the repo's own WIRE_JSON config, this branch against main:

buf	result
1.8.0 (what the Makefile downloads)	Field "1" on message "TeleportToRequest" moved from outside to inside a oneof
1.72.0 (current)	passes

Newer buf recognises the synthetic oneof of a proto3 optional field. Bumping the pinned version would clear the check without touching the rules; otherwise the block can be bypassed for this PR on the grounds above.