fix (stackY): Fix the point offset when set stackY.

[Runtus]

Checklist

• npm test passes
• benchmarks are included
• commit message follows commit guidelines
• documents are updated

Description of change

• 修复stackY生效时，散点位移和实际不重合的情况。
• 经过源码阅读发现，是因为散点图的底层渲染会取y和y1的均值作为最终的y，响应的point响应逻辑代码在此。所以导致他实际出来的效果会发生偏移，为了让改动最小化，所以直接在stackY的渲染代码中做了判断处理。

fixed: #6506

[pearmini]

@Runtus 优秀！不过可以看看这个 #4515 ，这样改分箱散点图会有问题吗？

[Runtus]

@Runtus 优秀！不过可以看看这个 #4515 ，这样改分箱散点图会有问题吗？

好嘞，我这边看看

[Runtus]

@Runtus 优秀！不过可以看看这个 #4515 ，这样改分箱散点图会有问题吗？

我刚刚看了下， #4515 展示没啥问题，因为其中代码指定了把y1指定为y的通道，原理其实和我改的地方一样，就是让散点图只有一个y通道，防止取均值。

关于分箱散点图，刚刚去测试了下，不会有影响，它的transform走的是bin，我只改了stackY的渲染逻辑，所以不会有影响。

[Runtus]

@pearmini 对了，再麻烦老哥看看CI报错，我在本地跑和这里跑是一样的错误，不知道是不是某个依赖包更新导致的CI跑挂了

[pearmini]

@Runtus 那挺好的！虽然在 transform 里面判断 mark 类型不是很推荐，但是这样对用户来讲确实是更好滴。CI 问题可能需要 @hustcc 看看了，是不是底层依赖升级了？

[pearmini]

这里还有一个种写法，仅供参考：

encode: {
  y0: inferredColumn(Y, fy), // Store original Y.
  y: column(V, fy),
  ...mark.type === 'point' && { y1: column(V1, fy1) }
}

[hustcc]

@pearmini 对了，再麻烦老哥看看CI报错，我在本地跑和这里跑是一样的错误，不知道是不是某个依赖包更新导致的CI跑挂了

ci 统一修复～