XMC: use packet-framed configuration stream by default

[spr334-a]

Summary

Make packet-framed XMC the default transport behavior. XMC now completes Login, remains in Configuration state, carries proxy bytes in xmc:data custom payload packets, and exchanges Minecraft Configuration Keep Alive packets.

The user-facing mode setting and the raw post-encryption path have been removed. This is wire-incompatible with the previous XMC behavior, so both endpoints must be updated together.

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，而是让加密后的流量形态更接近正常游戏：完成阶段转换，下行以较大的区块数据突发为主，上行保持较小的控制数据。合法包结构更多是为了保证实现一致性；对被动识别真正有意义的是长度和时序整形。

[RPRX]

弄成默认的，别加 mode 参数，Finalmask 的东西随便 break