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/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) {