视觉探针的夹具是 1×1 PNG，会得出「没有一个模型可用」的相反结论

## 探针会给出与事实完全相反的结论

`apps/api/scripts/probe-bailian-vision.mjs` 内嵌的 `TINY_PNG_BASE64` 是一张 **1×1** PNG。原样跑，**每一个**候选模型都返回：

```
HTTP 400：{"error":{"code":"invalid_parameter_error",
"message":"The image length and width do not meet the model restrictions. [height:1 or width:1 must be larger than 10]"}}
```

按脚本**自己的判据**，全 400 会输出：

> 「没有一个候选可用。不要把任何一个名字写进 KERNEL_MODEL_VISION_IDS——」

**这是错的。** 2026-09-10 实测：换成 32×32 黑白棋盘 PNG 后，`qwen3.8-max` / `qwen-vl-max` / `qwen-vl-plus` / `qwen-vl-ocr` / `qwen3-vl-plus` **五个全部 200 并准确描述了图像内容**（例如 "A 2x2 checkerboard pattern of black and white squares."）。

## 为什么这是重要缺陷而不是小夹具问题

那个 400 恰恰是**反向证据**——报错来自上游的**图像尺寸校验器**，证明 `image_url` part 已经被接受并路由进了视觉链路。**用 1×1 图去问「这个模型能不能看图」，判据在这个夹具下无法被证伪**：能看图的模型和不能看图的模型会得到同一个结果。

这正是本仓最贵的那个形状：**替身/夹具产不出被测事实的形状**。而且这次的后果是**主动误导**——脚本会斩钉截铁地告诉下一个人「一个都不可用」，那个人照做就会把一条本来能用的能力永久关掉。

真实后果已经发生过一次的近似版：`KERNEL_MODEL_VISION_IDS` 默认值 `qwen-vl-max,qwen-vl-plus` 不含内核实际用的 `qwen3.8-max`，导致用户上传的图**从来没进过模型输入**，而界面表现得和「模型不支持视觉」一模一样（#3346 / PR #3350）。

## 要求

- 换成一张**尺寸合法**的最小测试图（>10×10），并在脚本头注写明**为什么不能用 1×1**，避免有人日后为了「更小更快」再改回去。
- **三步反证**：把图换回 1×1 → 断言变红（贴真实输出）→ 换回合法尺寸 → 恢复绿。**只贴绿不算数**（本仓已九次「全绿但空转」）。
- 断言要能区分「模型真的看到了图」与「请求被上游拒绝」，**不能只判 HTTP 200**。
- 顺带：脚本默认 base_url 是公共 `dashscope.aliyuncs.com`，而本项目实际用的是**私有 MaaS 端点**（在 `KERNEL_MODEL_BASE_URL`）。不覆盖就会探到另一个账户的另一套模型清单——请在脚本里显式处理或至少在头注警告。

Start with apps/api/scripts/probe-bailian-vision.mjs and run it against the configured endpoint, checking how TINY_PNG_BASE64 and the response判据 are used. Replace the 1×1 fixture with a legal image, document the size and private KERNEL_MODEL_BASE_URL requirement, and verify the three-step 1×1 failure and valid-image success behavior, including evidence that the model described the image.

Written by the indexing model from the issue text.