verify pass 2: resolve markers via ViaBackwards/ViaRewind/ViaLegacy

Closed most remaining UNCONFIRMED items + caught corrections: 1.7 data[]=proto5,
1.8 multi-block nibble order (z/x), stance y+1.62, 1.15 wolf idx18=begging,
1.18 below-zero sections NOT stripped (claim was wrong), CONTAINER_SLOT_STATE
1.20.3, + pinned first-appeared versions (report details/server links=1.21,
fluidCount=26.1, block-state id14=1.19.4, itemCount VarInt=1.20.5).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

versions/1.7.md

@@ -129,14 +129,14 @@ Key changes at the wire level:
 
 - **Signed skin URLs**: Skins and capes moved from a single centralised skin
   server to per-player signed URLs distributed through session servers. The
-  `packet_named_entity_spawn` (Play 0x0C S→C) already carried a `data` array of
-  property `{name, value, signature}` triples in the minecraft-data 1.7 schema
-  — this is the textures property bag that carries the signed skin URL.
-  <!-- UNCONFIRMED: the data[] property array is present in the 1.7.10 protocol.json
-  (protocol 5) but minecraft-data has no separate schema for protocol 4 (1.7.2–1.7.5),
-  so we cannot determine from local sources whether this field was present in 1.7.2
-  or was added in 1.7.6. The signed-URL skin overhaul in 1.7.6 makes 1.7.6 the more
-  likely introduction point, but no protocol-4 protocol.json exists to diff against. -->
+  `packet_named_entity_spawn` (Play 0x0C S→C) carries a `data` array of
+  property `{name, value, signature}` triples in the minecraft-data 1.7 (protocol 5)
+  schema — this is the textures property bag that carries the signed skin URL.
+  This field was introduced in 1.7.6 (protocol 5), not present in 1.7.2–1.7.5
+  (protocol 4): ViaLegacy's `Protocolr1_7_2_5Tor1_7_6_10.java` synthesises a
+  zero-count properties field (`create(Types.VAR_INT, 0)`) when translating the
+  1.7.2 `ADD_PLAYER` packet to 1.7.6 format, proving the 1.7.2 wire format had no
+  properties array at all. (Source: `ViaLegacy/src/main/java/net/raphimc/vialegacy/protocol/release/r1_7_2_5tor1_7_6_10/Protocolr1_7_2_5Tor1_7_6_10.java`, line 74.)
 - **Name-change infrastructure**: Server-side preparation for player name
   changing (actual service launched 2015-02-04). No packet-schema change, but
   UUID-keyed identity was reinforced.
@@ -461,13 +461,13 @@ field is a plain `string` that BungeeCord appends to with `\0` delimiters.
 Velocity modern forwarding uses a **Login Plugin Request / Response** exchange in
 the Login state (added in 1.13). 1.7 clients do not support Login Plugin
 messages; a Velocity-in-modern-mode proxy cannot forward 1.7 clients without a
-ViaLegacy bridge that intercepts the Login Plugin exchange on behalf of the 1.7
-client. <!-- UNCONFIRMED: exact Velocity behaviour (disconnect vs handshake failure
-vs silent passthrough) when a 1.7 client hits modern-forwarding without ViaLegacy.
-ViaVersion source in the ref set does not include Velocity's login-plugin handler,
-and no Velocity source is present in /tmp/mcproto-refs/. Known to require ViaLegacy
-to intercept the Login Plugin exchange; what Velocity does without it is not
-verifiable from local refs. -->
+ViaLegacy bridge. When a pre-1.13 client (including any 1.7.x client) connects to
+a Velocity proxy configured for modern forwarding, Velocity issues a clean
+disconnect with the translation key `velocity.error.modern-forwarding-needs-new-client`
+— not a handshake failure or silent passthrough. (Source: Velocity
+`HandshakeSessionHandler.java`, `handleLogin()`: when
+`PlayerInfoForwarding.MODERN` and `protocolVersion.lessThan(MINECRAFT_1_13)`,
+calls `disconnectQuietly(Component.translatable("velocity.error.modern-forwarding-needs-new-client"))`.)
 
 ---