feat(file): 上传预检/秒传/批量处理/预览 + 缩略图（P2-7）与 H5 独立 dev server（P2-9）

缩略图：StorageService.thumbUrl(path, expire, maxLongSide)，七牛在**签名之前**拼
imageView2/2/w/h（拼在签名之后必 401），本地存储回退原图，让调用方不必判断当前是什么存储。
实测 1454KB → 36KB（2.4%）、1600×1200 → 400×300。

F-73：秒传原来排在份数检查之后 → 网络重传得到「你超了」而不是「你已经传过了」。

H5 dev server：vite 加 /api 代理 + .env.development 把 VITE_API_BASE 设空串，
改一行不用再 build:h5；三端行为不同（dev→代理 / 构建产物→location.origin / 小程序→写死）。

验证：新增 e2e-m9-thumb.py 12/12（打到真实七牛）、e2e-m8-orgfile 54/54；
H5 与小程序两端构建都验过。

frontend-mp/vite.config.ts

@@ -1,7 +1,41 @@
 import { defineConfig } from "vite";
 import uni from "@dcloudio/vite-plugin-uni";
 
-// https://vitejs.dev/config/
+/**
+ * 学生端（uni-app）的 vite 配置。
+ *
+ * ## ⚠️ 这里加了一个 dev proxy，解决一个真实的开发痛点
+ *
+ * H5 **没有独立 dev server** 是之前的状态：`src/config/index.ts` 里
+ * `API_BASE_URL = location.origin`，而 vite dev server 不代理 `/api`，
+ * 于是 `pnpm dev:h5`（另一个端口）打不到后端 8080 上的接口 ——
+ * 只能 `pnpm build:h5` 再访问**后端托管的产物**（http://localhost:8080）。
+ *
+ * 后果不只是"麻烦一点"：**改一行要等一次完整构建**，而学生端正是改得最多的地方
+ * （表单、上传、核验页），反馈慢会直接改变开发方式 ——
+ * 人会倾向"一次改一堆再构建"，而那时候出问题已经分不清是哪一处引起的。
+ *
+ * 所以这里补两件事（**缺一不可**）：
+ *   ① 本文件的 `server.proxy`：把 `/api` 转发到后端；
+ *   ② `src/config/index.ts` 里让 `API_BASE_URL` 优先取 `VITE_API_BASE` ——
+ *      否则它仍然是 `location.origin`（= dev server 自己），代理配得再对也没用。
+ *
+ * ## ⚠️ 微信小程序端不受影响
+ *
+ * 小程序的请求不走 vite（它在微信开发者工具里跑），而且微信的
+ * **request 合法域名是固定白名单**，配不了 localhost —— 所以那边照旧。
+ * 由 `#ifdef H5` 条件编译保证。
+ */
 export default defineConfig({
   plugins: [uni()],
+  server: {
+    port: 5174,
+    proxy: {
+      // 与 frontend-pc 同一做法：dev server 上的 /api 转发到本机后端
+      "/api": {
+        target: "http://localhost:8080",
+        changeOrigin: true,
+      },
+    },
+  },
 });