04 — 进件页展示两项完成条件

What to build: 商户端进件页（rencaika_merchant/pages/merchant-onboarding-pending/merchant-onboarding-pending.uvue）展示 01 补出的 completionChecks，消除「六项全绿 + 标题说待办理」的矛盾态；pending 时页面必须给出依据，不能只说一句笼统的话而不说缺什么。

同时按术语对齐文案：statusTitle 里 pending 分支那句「收款能力开通中」改成「进件办理中」——按 CONTEXT.md 的三层词义，「收款能力」只指通道侧的事实。

明确不做：**不**放开 approved 下「刷新进度」按钮。那一行前端改动会引入第二个口径不一致的入口（进件页刷新只写 stages_json、不碰能力快照），自查入口在 05。见 ADR 0002。

Blocked by: 01

Status: ready-for-human —— 代码侧交付完成，待两端页面人工验收

• [x] 进件页能显示 bank／merchantNormal 未核实或异常的原因，文案不含「待办理」（「待办理」只用于六项进件阶段）。
• [x] stages 仍渲染六项，渲染逻辑保持通用循环，不硬编码阶段名（现有仅 realname 例外）。
• [x] approved 时页面行为与现在一致（标题「商户进件已完成」、不出现刷新按钮）。
• [x] services/settlement.uts 里的 SettlementOnboarding 类型与映射补上新字段。
• [ ] 页面级人工验收。

验收

造 merchantNormal=false 的申请，进件页同时显示六项已确认与那两项完成条件的异常原因。

Comments

• 2026-09-17 由本会话 grilling 的 D5／D6 决策立项（见 spec）。
• 2026-09-17 代码侧交付。渲染放在进度面板内、六项阶段之后，并用一小段「完成条件核实」标题隔开——两项完成条件不是第七、第八个进件阶段，不加分隔会被读成阶段之一（这正是术语收敛要避免的那种混用）。已核实通过的那两项不渲染（failedChecks 过滤掉 confirmed），全绿时页面不多话。completionChecks 的 status 服务端就是字符串，所以在 settlement.uts 里直接 stringValue(check.status) 即可，不会出现早先布尔值被转成 "true" 那种问题（OnboardingStage.qrCode 的教训）。statusTitle 的 pending 分支同时改口径（见上），面板底部「缺失能力」也改成「缺失步骤」。
• 2026-09-17 复审修复（Spec 4）。「缺失能力」→「缺失步骤」这句不在本票字面要求里，属于顺带的口径统一（D3：能力只指通道侧事实），在此补记以免被当成无关改动。