docs(card): 删掉「格子数与图数量永远相等」这句错误断言 #3

上一版（工单 #2）在这里写「这样"格子数"和"图数量"在结构上永远相等」。
这句话是错的，也正是工单 #3「21 格」的思想源头：

  keys 按 poster **去重**收集、还卡 20 张上限
  list 按 **行** 过滤、无上限，还会再裁偶数

两个集合基数不可能恒等，正确的说法只是「≤，不是 ==」。
把错误的断言留在注释里，下一个人会照着它推理，再踩一次同样的坑。

本次只改注释，无逻辑变更（守卫 1324/0、v97 反证 13/0 均通过）。

entry/src/main/ets/data/FbCardMediaData.ets

@@ -246,9 +246,12 @@ export async function fbMovieCardBuild(ctx: common.Context): Promise<FbMovieCard
                     纯文本列表，30 条都可以留着，滑得动就行。
        · `list`  → `listJson`，给 **4×4 / 6×4 海报墙**。这是两列大图，
                     **没图的格子就是一块淡紫占位**，等于坏格。
-                    ⇒ 只保留**真的配到图**的行，长度天然 ≤ `CARD_IMG_MAX`。
+                    ⇒ 只保留**真的配到图**的行，长度 ≤ `CARD_IMG_MAX`。
-                    这样"格子数"和"图数量"在结构上永远相等，
+                    ⚠️ 注意是 **≤，不是 ==**：`keys` 按 poster 去重收集，
-                    就算某张海报 404、或某条本来就没 `poster_key`，也不会冒出一个空格子。 */
+                    `list` 这一版也按 poster 去重（工单 #3），两边基数才对齐；
+                    但它们**不是同一个集合**（`keys` 卡 20 张上限、`list` 还会被裁偶数），
+                    别写成"结构上永远相等"——v95 就是这么写的，然后长出了 21 格。
+                    只要保证"每格都有图"即可，具体条数以 `list` 自己的去重+裁剪为准。 */
   const bag: FbImageBag = await fbAttachPosters(ctx, token, rows);
   out.formImages = bag.formImages;
   out.imgFds = bag.imgFds;