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/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
+    })
 }