XMC: add packet-framed configuration stream mode

[spr334-a]

Summary

Add an optional packet-framed XMC mode that completes Login, remains in Configuration state, carries proxy bytes in xmc:data custom payload packets, and exchanges Minecraft Configuration Keep Alive packets.

The existing raw mode remains the default. Both endpoints must set mode to packet to enable framing.

This also fixes bounded packet parsing, partial CFB8 writes, n+EOF reads, offline UUIDv3 generation, random-source handling, and shared-secret validation.

This intentionally does not emit version-specific Play or Chunk Data packets.

Validation

• go test -count=20 ./transport/internet/finalmask/xmc
• go test ./transport/internet/finalmask/...
• go test ./infra/conf -run '^$'
• go vet ./transport/internet/finalmask/xmc ./transport/internet/finalmask
• go build ./main

[Fangliding]

额 这和之前的模式区别是什么

[spr334-a]

额 这和之前的模式区别是什么

之前的 raw 模式只在前面完成 MC 握手和加密协商，之后就直接传输上层字节流，不再按 MC 数据包格式封装。
新增的 packet 模式会继续完成 Login Success / Login Acknowledged，停留在 Configuration 状态，将数据分片放进合法的 custom_payload 包，并使用 MC Keep Alive

[spr334-a]

后续可以再完整进入 Play 阶段：服务端下行的大流量使用合法的 Chunk Data 承载，客户端上行继续使用 Play custom_payload，心跳切换为 Play Keep Alive。由于 Registry 和 Chunk 格式与 MC 版本强相关，建议拆成后续独立 PR。

[Exclude0122]

我觉得没必要，因为开启加密以后 中间人看不出来发的是不是真 mc 包。可能有时序和包大小问题，不过现阶段我觉得不会有专门检测这个的

[spr334-a]

我觉得没必要，因为开启加密以后 中间人看不出来发的是不是真 mc 包。可能有时序和包大小问题，不过现阶段我觉得不会有专门检测这个的

AES/CFB8 开启后确实无法解析 Packet ID 和 Payload，这点认同。但 raw 模式会在 Encryption Response 后立即进入任意字节流，缺少正常 MC 会话中的 Login Success、Configuration、Play 等阶段。虽然状态本身不可见，这些阶段产生的方向、首包大小、间隔和后续流量分布仍然可以统计。
后续补充Play/Chunk 模式的主要价值不是让中间人解析出合法 Chunk ID，而是让加密后的流量形态更接近正常游戏：完成阶段转换，下行以较大的区块数据突发为主，上行保持较小的控制数据。合法包结构更多是为了保证实现一致性；对被动识别真正有意义的是长度和时序整形。