6520f1c97c
配合后端把三条报废旁路收口到审批流。
【删除】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，行为与改造前完全一致。