[Test]: Stabilize zero-allocation envelope reader gate across isolated runners

[SunSi12138]

现象

SharpLink.UnitTests.Server.ServerRequestEnvelopeReaderTests.ReadSteadyStateWithoutOptionalFieldsShouldAllocateNothing 在受控的远端 Release 测试环境中偶发报告极小分配，即使代码基线也会复现。

已确认的证据

在 192.168.31.242、.NET 10、固定 CPU 4–15、flock 串行、相同短 TMPDIR / DOTNET_CLI_HOME 下：

• dev@2af21dc2ad340b398bf3a9f208c28058111df820：目标测试失败，40 bytes over 20000 calls。
• refactor(runtime): add dispatcher detach completion #136 候选 ed140b46f490947f9d9a686aaa27b42d3acc3b8a：同一目标测试同样失败，40 bytes over 20000 calls。
• 候选随后完整 Unit 重跑通过，820/820。

候选与基线在该 Server envelope reader 路径没有源码差异；#136 只改动 stream dispatcher 生命周期。因此这不是 #136 的性能回归，但当前断言/预热或测量隔离存在非确定性。

期望

• 找出这 40B 的来源，或让测量在真正稳态后、以不掩盖真实回归的方式确定化；
• 保持真实零分配门禁，不以任意阈值或重试掩盖回归；
• 在同一进程和隔离进程中反复运行目标测试都稳定；
• 记录在 CI/远端门禁中应如何处理已证实的基线波动。

非目标

不把这个测试问题混入 Phase 14/#136 的功能改动。

[SunSi12138]

已完成定位和处理。

结论

对比 issue 中的基线 2af21dc、#136 候选以及当前代码后，确认 ServerRequestEnvelopeReader 的无可选字段读取路径没有源码回归，也不存在每次调用 40B 的稳定分配。

问题位于测试测量边界：

• 原测试只直接预热 ServerRequestEnvelopeReader.Read 2,000 次；
• 实际被测的调用方循环本身仍可能在分配窗口开启后触发 tiered compilation、dynamic PGO 或 OSR 的一次性运行时工作；
• GC.GetAllocatedBytesForCurrentThread() 会把同一测试线程上的这类一次性工作计入结果，因此出现了偶发的 40B，而不是 envelope reader 每次调用产生分配。

修复

• 将实际测量循环提取为禁止内联的 ReadBatch；
• 在测量前用完全相同的循环执行 100,000 次，使调用方循环和叶子方法都进入稳态；
• 在测量窗口外初始化线程分配计数器；
• 正式门禁仍只测量一次并严格要求 allocated == 0，没有增加容差、失败重试或 best-of 选择；
• 新增了 CI/远端验证文档，说明 Release 构建、固定环境、串行执行以及独立进程重复验证方式。

验证

• 完整 Release Unit：826/826 通过；
• 目标门禁在 10 个独立新进程中重复执行：10/10 通过；
• 严格零分配断言保持不变。

因此该现象已经确定化处理，并且不会掩盖真实的逐调用分配回归，关闭此 issue。