feat(scrap): 前端适配报废审批收口

配合后端把三条报废旁路收口到审批流。

【删除】api/scrap.ts 的 createScrap()
  对应后端已删的 POST /api/v1/scrap。该函数此前已是死代码（全仓无调用方），
  页面早已切换到申请-审批-按单执行流程。

【改造】不良品看板 views/stock/defective/index.vue
  「报废销毁」→「申请报废」：弹窗新增「指定审批人」（必填，复用
  getApproversList）。API 由 scrapDefective 改为 submitDefectiveScrapRequest。
  ★ 弹窗与成功提示都明确写出「在管数量不会立即扣减，待审批通过并执行后才
    扣减」—— 申请不预占 remaining_qty，行数据看起来毫无变化，不说明会诱发
    重复提交。

【改造】借还记录页 views/transaction/records.vue
  「报废」→「申请报废」：弹窗新增「指定审批人」（必填）。原先内联的
  request() 调用挪到 api/transaction.ts 成为 submitBorrowScrapRequest，
  与全仓 API 分层一致。确认框文案改为「提交后进入审批流程」。
  顺带清理 canScrap 里硬编码的 `username === 'IRIS'` 后门 —— 该账号在
  sys_user 表中根本不存在，属死代码。

【改造】按单报废执行页 views/operation/scrap/create.vue
  按 scrap_mode 把批准明细分流：
    · scan 项（库存行 / 在管不良品）—— 走原有扫码购物车，逻辑不变
    · auto 项（借出未还）—— 实物在借用人手上、无法扫码，放入**只读区块**
      展示，不进购物车（购物车语义是「扫码证据」，混入会让扫码校验失效）
  纯 auto 单隐藏整个扫码区并提示「本单无可扫码物料，将按批准数量直接执行」；
  扫码进度只统计 scan 项（否则进度条永远满不了，会让操作员误以为没扫完）；
  提交守卫放宽为「购物车与 auto 项都为空才拦」；确认框追加
  「另有 N 项将按批准数量自动执行」，避免操作员误以为只报废了扫到的那些。
  matchKey 同步加入来源表（与后端 _match_key 保持逐字同口径），
  sourceLabel 补两种新来源的中文名。

存量单据没有 scrap_mode 字段，前端回落为 scan，行为与改造前完全一致。

inventory-web/src/api/inbound/return.ts

@@ -71,15 +71,26 @@ export function restockDefective(id: number, data: { restock_qty?: number; remar
 }
 
 /**
- * 报废销毁：在管坏件确认无法维修时销毁。
+ * 提交在管坏件的**报废申请**（需审批人审批，通过后由库管执行报废）。
+ *
+ * ★ 已由「直接报废」改为「申请」：
+ *   报废一律需审批（后端 SCRAP_ALWAYS_REQUIRES_APPROVAL）。原
+ *   POST /defective/<id>/scrap 直接写 trans_scrap 并扣在管量，绕过审批，
+ *   构成职责分离漏洞（同一库管可自行宣告实物销毁而无人复核），已删除。
+ *
+ * ★ 副作用提醒：申请**不预占**在管量，`remaining_qty` 提交后不变。
+ *   前端必须提示用户「待审批并执行后才会扣减」，否则会诱发重复提交。
  *
  * @param id   在管台账 id
- * @param data { scrap_qty?: number, reason: string }
- *             reason 必填；scrap_qty 缺省 = 全部剩余在管量
+ * @param data { scrap_qty?: number, reason?: string, approver_id: number }
+ *             scrap_qty 缺省 = 全部剩余在管量；approver_id 必填
  */
-export function scrapDefective(id: number, data: { scrap_qty?: number; reason: string }) {
+export function submitDefectiveScrapRequest(
+    id: number,
+    data: { scrap_qty?: number; reason?: string; approver_id: number },
+) {
     return request({
-        url: `/inbound/stock/defective/${id}/scrap`,
+        url: `/inbound/stock/defective/${id}/scrap-request`,
         method: 'post',
         data
     })

inventory-web/src/api/scrap.ts

@@ -9,14 +9,11 @@ export function scanBarcode(barcode: string) {
     })
 }
 
-// 2. 提交报废单
-export function createScrap(data: any) {
-    return request({
-        url: '/v1/scrap',
-        method: 'post',
-        data
-    })
-}
+// [已移除] 直接报废 createScrap —— 对应后端 POST /api/v1/scrap，该接口绕过
+// 审批流直接写 trans_scrap 并扣库存，与系统自陈的「报废一律需审批」规则冲突，
+// 构成职责分离漏洞（同一库管可自行宣告实物销毁而无人复核），已整体删除。
+// 所有报废改走：submitScrapRequest → approveScrapRequest → executeScrapByRequest。
+// 该函数此前已是死代码（全仓无调用方），删除无行为影响。
 
 // 3. 报废记录列表查询
 export function getScrapRecords(params: any) {

inventory-web/src/api/transaction.ts

@@ -230,4 +230,30 @@ export function dispatchBorrow(data: {
         method: 'post',
         data
     })
+}
+
+/**
+ * 提交「借出未归还」的**报废申请**（需审批人审批，通过后由库管执行报废）。
+ *
+ * ★ 已由「直接报废」改为「申请」：
+ *   原 POST /v1/transactions/borrow/scrap 直接写 trans_scrap 并扣总库存，
+ *   绕过审批、构成职责分离漏洞，已删除。现统一走 申请 → 审批 → 执行。
+ *
+ * ★ 副作用提醒：申请**不立即改变**借用记录状态，提交后该笔仍显示为未归还。
+ *   前端必须提示用户「待审批并执行后才会标记为已报废」。
+ *
+ * @param data record_ids: trans_borrow.id 列表（按整条待还量报废）
+ *             reason?:    写入申请单备注
+ *             approver_id: 必填，指定审批人
+ */
+export function submitBorrowScrapRequest(data: {
+    record_ids: number[]
+    reason?: string
+    approver_id: number
+}) {
+    return request({
+        url: '/v1/transactions/borrow/scrap-request',
+        method: 'post',
+        data
+    })
 }