[故事]: 将 cudf-polars 自身的测试套件缩减到上游 polars 无法覆盖的范围

cudf_polars/tests/ (计划节点测试)、tests/expressions/ 和 tests/streaming/ 一起运行了大约 2,600 个测试，其中很大一部分重复了上游 polars 套件中已经存在的覆盖范围（在 CI 中运行 GPU 引擎）。已经在上游覆盖了构建 LazyFrame、在无关数据上应用一个普通 polars 操作，并检查 GPU 输出与 CPU 相匹配的测试。在过滤掉这些测试后，剩下的是一个较小的、真正本地的集合：cudf-polars 的未支持操作/回退表面、GPU 核函数数学边缘情况（NaN/inf/溢出、小数点精度、dtype 界限）以及我们自己的配置/引擎/优化器内部（GPUEngine 配置、StreamingOptions、连接过滤推迟、分区请求传播、引擎后端）。上游中没有任何测试可以测试这些内容，因为 polars 没有对这些内容的概念。一些流特定的测试还以一种不合理的方式具有内省性。它们通过手动构建 IR 节点字段或 repr 字符串来断言，而不是通过可观察的行为，而公共 API 测试则可以同样很好地覆盖相同的内容。目标：剔除重复的测试，保留（或重写为行为测试）那些测试真正属于 cudf-polars 专用的测试，以及那些测试上游公共 API 行为的测试不测试，且不依赖 cudf-polars，而是将其提交到上游，而不是保留在本地。运行上游套件时，使用小分区大小（ --inject-gpu-engine-blocksize=small）已经存在作为一种机制，可以直接吸收大部分多分区正确性测试。例外是扫描/IO 测试，这些测试在上游中被明确跳过，因为它们太慢，需要在删除这些测试之前解决此差距。在整个过程中还值得解决的问题：上游 polars 任务目前使用 raise_on_fail=False，因此它不会像本地测试那样捕获 CPU 回退漏洞。删除本地回退测试而不在上游运行中添加回退跟踪将导致覆盖范围减少，而不是清理。在基于“这种行为看起来像标准 polars 行为”的判断时，我们应该用实际覆盖数据来支持它。pytest-cov 支持 动态上下文（ --cov-context=test），它记录哪个测试覆盖了哪一行。作为第一步，即使是简单的行覆盖差异也有帮助：分别运行 polars 测试任务和 cudf-polars 测试任务，合并两个覆盖报告，查找只有本地任务触及的 cudf-polars 行。这些是本地套件真正覆盖的 cudf-polars 部分，它们是保留哪些应留在本地，哪些应删除的最有力信号。