[approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options)

[os-zhuang]

Part of #7213 (problem 4: three vocabularies for one request).

Facts (verified on origin/main, 2026-08-10)

• Object-metadata bundle (plugin-approvals; served to every surface that renders sys_approval_request): packages/plugins/plugin-approvals/src/translations/zh-CN.objects.generated.ts:44 has pending: "待处理"; the my_pending view is named "我的待办" (around :88-95). The Approvals Inbox (objectui approvalsInbox.*) and the account-app nav label (packages/platform-objects/src/apps/translations/zh-CN.ts:21) say 待我审批 / 待审批 for the same things — three vocabularies with no shared keys.
• The en bundle ships raw enum values as labels: en.objects.generated.ts:43-49 (pending: "pending", approved: "approved", …) — unhumanized, unlike zh/ja/es.
• These files are .generated.ts; there is an extraction config at packages/plugins/plugin-approvals/scripts/i18n-extract.config.ts, and check:i18n / check:i18n-coverage / check:app-nav-i18n run in lint.yml. Work through the pipeline if it is the source of truth (verify first); if the files turn out to be hand-maintained despite the name, edit directly and record the evidence in the PR body.

Canonical glossary (align to the Approvals Inbox wording)

• zh-CN status options: pending: 待审批 (the change); approved: 已批准, rejected: 已拒绝, recalled: 已撤回, returned: 已退回修改 (verify current values; keep whatever already matches).
• zh-CN my_pending view label: 待我审批 (was 我的待办); align the empty-state wording accordingly.
• en status options: Pending / Approved / Rejected / Recalled / Returned; en my_pending label stays "My Pending".
• ja-JP / es-ES: align the view label with the nav wording where it diverges (ja-JP.ts:21 承認待ち, es-ES.ts:21 Aprobaciones pendientes); do not invent translations beyond this glossary.

Acceptance criteria

• A sys_approval_request row rendered through the generic object surfaces uses the same zh status word (待审批) as the Approvals Inbox — problem 4 of [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 closed at the bundle level.
• en no longer shows raw enum values as labels.
• translations/bundle-ownership.test.ts, approval-vocabularies.test.ts, and any pinned label expectations updated (flipped pins keep bearing load — assert the new wording, do not delete assertions); check:i18n / check:i18n-coverage green; changeset present (user-visible).

Out of scope

• Sharing one key-space across the three layers (that is the objectui#2763 rebuild's outcome); objectui-side approvalsInbox.* wording (already the canonical wording); nav-metadata changes (separate sub-issue of [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213).

[os-zhuang]

Claim: PM loop round 1 (maintainer-directed dispatch for #7213)
Session: session_01L9U1G2piXmYrhYQX96XUyv
Branch: claude/issue-7232-approval-status-vocab
Worktree: objectstack-issue-7232
Domain: domain:services
File surface: packages/plugins/plugin-approvals/src/translations/**, packages/plugins/plugin-approvals/scripts/i18n-extract.config.ts (or the true label source it extracts from), related tests in the same package
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: batch mate #7231 lands in objectui (different repo). #7234 (pm:blocked, same parent) also touches plugin-approvals but rides a later round after #7231 merges — not in this batch. No in-flight claim or open PR on plugin-approvals translations per search at claim time.

---

Generated by Claude Code

[os-zhuang]

ACCEPT — PR #7271 (review by the epic PM session, verified against GitHub, not the report):

• Shipped: the four plugin-approvals bundles now carry the [approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232 glossary — zh pending 待处理→待审批, my_pending 我的待办→待我审批 (+ empty-state), en statuses humanized, ja/es view labels aligned to the nav wording. Status values untouched.
• Mechanism finding recorded: the dispatch's "fix at the extraction producer" hypothesis was half-falsified with two-directional probes — os i18n extract owns bundle structure, leaf values are hand-maintained and --merge-preserved; en's raw labels trace to Field.select normalizing bare enum strings to label=value. Correct handling.
• Net-new pin, not a flip: nothing pinned this wording anywhere (which is how three layers drifted). The new approval-status-vocabulary.test.ts asserts through the real resolvers (proving the bundle is reached), adds a raw-enum-leak ratchet across four locales, and — the load-bearing part — a cross-package parity case tying this plugin's my_pending label to platform-objects' nav_account_approvals label for zh/ja/es, so either layer reworded alone goes red. Reverse verification 5/6 red in the predicted direction.
• File surface: 6 files, all inside the claim; changeset present; no releases/ADR paths. CI verified per-job: 25 check runs, ESLint / TypeScript Type Check / Test Core (3) / Dogfood gates (3+CLI) / Temporal Conformance all success, zero failures.
• Residual, deliberately not changed (scope boundary of this card, flagged in the PR body): ja-JP status.options.pending is 保留中 while 承認待ち is used elsewhere in the same bundle — a one-line follow-up if the ja status word should align too; left for triage to grade.

Next: PR flipped ready + queued. Once it lands, #7234 (account/setup nav → approvals:inbox) dispatches — both its upstreams (objectui#4071 merged; this PR, same-package serialization) will then be satisfied.

---

Generated by Claude Code