feat: 蝦皮数据页分页与状态筛选 (#43)

导入真实样本后 /shopee 一次吐 3.4MB / 5195 行。但只加分页会把问题从
「5195 行糊在一起」变成「260 页里藏着 6 个」——那 6 个待补规格的商品
仍然找不到。所以分页和状态筛选一起做。

HTML 3.4MB → 16.7KB。

状态条显示全量而不是本页：「共 5195 个商品 · 第 1/260 页」。
显示「共 20 个商品」会让操作员以为总共就 20 个。筛选后显示筛选结果
总数：「待补规格：6 个商品」。

列表查询和 COUNT 共用同一套筛选条件拼装。分开写两份 WHERE，迟早
有天忘了给 COUNT 也加条件，页码算错而且没人发现（#19 踩过一次）。

page 越界兜到最后一页而不是显示空表格——空表格会让操作员以为数据没了。
总数为 0 时显示「第 1/1 页」，不出现「第 1/0 页」。

「待补规格」用 EXISTS 不用 JOIN+DISTINCT：一个商品有多个失败 SKU 时
JOIN 会出重复行，DISTINCT 又让 LIMIT/OFFSET 的行为难推理。

分页控件是 <a href> 纯 GET，浏览器前进后退和书签都正常。首末页用
<span class="disabled"> 禁用，语义上不再是链接，不只靠颜色区分。

这是全项目第一个分页页面，通用逻辑单独放 service/pagination.go 供
后面四页复用，规则写进 05 §3.2 而不是蝦皮页那一节（#34 踩过这个错）。
05 §3 的每页条数从「建议 50」改为「统一 20」并写明理由。

实现踩到 html/template 的 URL 上下文转义：夹在字面量 & 中间的动态内容
会被整体当成一个参数值转义，?/= 变成 %3F/%3D 让链接失效。改为在 Go 里
把整段 URL 拼好，模板作为单个 pipeline 输出，并加了回归测试。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/admin/01-requirements.md

@@ -85,7 +85,14 @@ PDD 商品之所以单独一个模块，是因为它在数据上就是**独立
 
 ### 4.1 蝦皮数据模块
 
-**顶部工具条：** 导入按钮、商品 ID 搜索框、搜索按钮、删除按钮、批量采集按钮。
+**顶部工具条：** 导入按钮、状态筛选（全部 / 待补规格 / 未填 PDD 链接 / 已填链接）、
+商品 ID 搜索框、搜索按钮、删除按钮、批量采集按钮。
+
+`[必须]` 状态筛选是**刚需**，不是锦上添花（工单 #43）：本页的主要用途是维护
+（找出需要补规格的商品、找出还没关联 PDD 链接的商品），只靠商品 ID 搜索的话，
+操作员得先知道 ID 才能搜——而"哪些商品需要处理"恰恰是不知道 ID 的时候才要问的。
+实测样本 5195 个商品里只有 6 个待补规格，只做分页要翻 260 页才能找全，等于找不到。
+界面细节和筛选条件的 SQL 见 [05 界面规范](05-ui-specification.md) §4.1。
 
 **中间表格**（按 SKU 展开显示，数据来自商品表和 SKU 表联查）：