[Taure]

Closes #477. Closes #478.

Both found while documenting client-side prediction across the seven SDKs, and both are the same
shape: the handler does something guides/websocket-protocol.md does not describe.

Reworked after review. The first commit's approach to #477 did not work; architecture, security
and code review all independently reproduced it. Second commit fixes it properly. Both commits are
kept so the review thread still reads.

#477 - world.ack was not monotonic

player_ack is per-zone state (asobi_zone.erl:220) and a player is subscribed to their whole
interest ring, so at view_radius 1 a one-step crossing leaves them subscribed to the zone behind
them. That zone kept emitting its own frozen mark while the destination advanced, so payload.seq
went backwards and the prune-and-replay recipe the guide teaches re-applied consumed input.

What did not work. Dropping the entry in remove_entity. record_ack/3 runs unconditionally in
apply_inputs/4, so any input still queued for the departed zone re-creates it, and the tick prune
keeps it because the player is still subscribed. Reviewers reproduced the original symptom on the
branch in both orderings. The window is the common case: remove_entity is cast at
asobi_world_server.erl:1209 but world_zone_changed only at :1243, and the session rebind is
async, so input routed to the old zone mid-crossing is expected - and only prediction clients receive
acks at all, which means they are sending every frame.

What also would not have worked. Guarding broadcast_acks on is_map_key(PlayerId, Entities).
A player whose entity was removed by game logic - dead, awaiting respawn - is still connected and
still sending input, and would receive no acks at all while their prediction buffer grew.

The fix. asobi_player_session holds last_ack_seq and drops any world.ack that does not
advance it. The session is per WebSocket and dies with it, so the mark resets exactly when the
client's counter does. That holds whichever zone emits the frame and regardless of cast ordering.
The zone keeps recording, because only the zone knows the tick-to-state binding; only the
monotonicity claim moved.

world.ack is therefore monotonic per connection, the guide now says so, and the seven SDKs can
drop the running-maximum workaround they currently document. That follow-up is not in this PR.

#478 - data was a reserved key on world.input

payload	before	after
{"kind":"move","x":600}	verbatim	verbatim
{"data":{"x":1}}	#{x}	#{x}, deprecated + counted
{"kind":"fire","data":{"x":1}}	#{x}, kind dropped	verbatim
{"kind":"fire","data":"blob"}	#{}, all dropped	verbatim
"not an object"	invalid_payload (via badmap)	invalid_payload (explicit)

That fourth row is why asobi-unity sent world input into a void. Note the fix for Unity is
widgrensit/asobi-unity#46, not this - here that shape now arrives as #{~"data" => ~"..."}, which is
merely honest rather than useful.

Review turned up two more:

• A silent drop I introduced. The first commit turned a non-map payload into #{}, which a game
  cannot distinguish from legitimate empty input, and told the client nothing. world_input_data/1
  now returns {ok, _} | {legacy_unwrap, _} | invalid and the caller answers invalid_payload.
• A Medium in the sibling path. match.input's json:decode of a binary data was unguarded.
  json:decode/1 raises, landing in safe_handle_message/2's catch-all, which logs a stacktrace. At
  60 frames/sec/connection and 60 connects/sec/IP, roughly 9 sockets exhaust the logger's burst
  budget and blind every other log line on the node, auth failures included. Same class asobi#465
  closed for badmap. match_input_data/1 makes it total, and gives match.input the same contract.

The sole-key unwrap is reported as [asobi, ws, legacy_input_unwrap] and documented as deprecated
with a removal condition, so it can be retired against real traffic rather than frozen into the spec
by being written down.

Checks

fmt, xref, dialyzer (exit 0), eunit 1959 tests, 0 failures. elp eqwalize on all four
changed modules is identical to main (asobi_ws_handler 2, asobi_zone 2, asobi_player_session 0,
asobi_telemetry 1). The telemetry coverage test caught the new event missing from the attach list,
which is the check working.

Mutation-verified. Removing the session filter fails 4 of the 5 new session tests; the survivor
is the pass-through test, correctly. world_ack_rearms_in_the_zone_left_behind pins the zone-side
behaviour the filter exists to correct, so if a future guard lands in the zone that test says so.

[github-actions]

🟡 Code Coverage — 76.7%

7597 of 9905 lines covered.

---

🟡 ELP Lint — 180 warnings

199 diagnostics found. See job logs for details.