Validate: are we sending scenes the wrong position for other players?

While reviewing [ADR-245](https://adr.decentraland.org/adr/ADR-245) I found two things that look wrong in how we tell scenes about *other* players. **I have not confirmed either one in a running client** — that is what this task is for. Please validate first; both could turn out to be non-issues.

Unity Explorer is the reference here: it does the opposite in both cases, which is why I suspect we're the ones off.

---

## 1. Other players' positions may be wrong (the likely real one)

When a scene asks *"where is this other player standing?"*, the answer should be measured **from that scene's own corner** — not from the middle of the map. It looks like we're sending map-wide coordinates instead.

If that's true, then in any scene that isn't at the center of the map, other players would appear at wildly wrong spots — potentially hundreds of meters off. Meanwhile **your own** position would look perfectly correct, which makes it easy to miss. Anything that draws a marker over other players, checks who's nearby, or reacts to people walking around would misbehave.

The catch: it would look completely fine at parcel `0,0`, which is where most quick tests happen.

What makes me think it's real: the conversion code *is* there, it just seems to compute the corrected position and then send the uncorrected one. Unity does the conversion and has a comment explicitly saying it's required.

**How to validate:** two clients in a scene that is **not** at parcel `0,0`. Have the scene print the other player's position while they walk around, and compare with where they actually are. Then repeat the same test at `0,0`. If it only looks right at `0,0`, it's confirmed.

## 2. What happens when a lot of people are in one place

Each nearby player gets a slot number so scenes can tell them apart, and there are 224 of them. When they run out, we seem to hand out a number that's outside the agreed range — and give *every* extra person the **same** number, so scenes would likely see them as one person flickering between several people.

Unity handles this differently: it just doesn't expose those extra players to scenes at all, and logs a warning once.

This is much less likely to bite anyone in practice (224 people in one spot is a lot), so treat it as the lower-priority half. Reproducing it live is probably impractical — a code read plus a small test is a fine answer here.

---

## Good news

The main thing ADR-245 cares about — the **range** of slot numbers — we already match exactly. Bevy Explorer recently fixed exactly this in [bevy-explorer#1138](https://github.com/decentraland/bevy-explorer/pull/1138) and named us as one of the clients that already had it right. The rest of the ADR checklist also looks fine: all four player components reach every scene, and the primary player's position is present everywhere it should be.

## Where to look

Ours:
- `lib/src/avatars/avatar_scene.rs:1596` — the corrected position is calculated, then the uncorrected one is sent
- `lib/src/avatars/avatar_scene.rs:1234` — related `TODO: get real transform with scene_offset`
- `lib/src/avatars/avatar_scene.rs:800` — the out-of-range slot number when we run out

Unity, for comparison:
- `WritePlayerTransformSystem.cs:44` — *"Patches position to be scene-relative before sending it through CRDT"*
- `PlayerCRDTEntitiesHandlerSystem.cs:60` — returns early and warns instead of inventing a slot number

## Definition of done

- [ ] A clear yes/no on each of the two, based on actually running or testing it — not just reading code
- [ ] If confirmed: fix it (both look small) or split the fix into a follow-up issue
- [ ] If it's not a problem: close with a short note on why, so we don't re-litigate it later