[approvals][console] Bell badge sums unread notifications + pending approvals into one opaque number — surface the breakdown

[os-zhuang]

Part of #7213 (problem 5: scattered counts). Independent display fix — not part of the entry-convergence train.

Facts (verified 2026-08-10)

• The bell badge formula is totalBadge = deduped unread (topic,title) count + pendingApprovalsCount (packages/app-shell/src/hooks/useHomeInbox.ts:127-138; packages/app-shell/src/layout/InboxPopover.tsx). The approvals half has no dedicated count API — it is the total of GET /api/v1/approvals/requests?status=pending&approverId=….
• The home "pending approvals" card and the inbox tab count share that same source, so home says 8 while the bell says 9+ ([approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213's measurement) — users cannot reconcile the numbers, and [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 reads this as "counts disagree".

Scope (minimal display fix)

Keep the total, but make the popover show the two components as labelled rows/sections ("Notifications N" / "Pending approvals M") so the badge is explainable. Verify the current popover layout first; if it already sections the two lists, the fix may be as small as rendering per-section counts.

Acceptance criteria

• A user seeing bell "9+" can see in the popover that it is N notifications + M pending approvals, with M matching the home card / Approvals Inbox tab count.

[os-zhuang]

Reservation (not yet dispatched): this issue is part of the pm:epic train on #7213 — see the epic registration in that issue's body.
Session: session_01L9U1G2piXmYrhYQX96XUyv
Planned dispatch: round 2, after #7231's PR merges (same-package serialization — both touch objectui packages/app-shell).
The pm:queue label was removed on purpose: the epic parent's subtree is this issue's queue. Other PM seats (including the objectui whole-repo seat): please do not claim — the assignee + this comment are the reservation; it will be dispatched from the epic session.

---

Generated by Claude Code

[os-zhuang]

Dispatching now (round 2 of the #7213 epic; supersedes the reservation comment above).
Claim: PM loop round 2
Session: session_01L9U1G2piXmYrhYQX96XUyv
Branch: claude/issue-7233-bell-badge-breakdown
Worktree: objectui-issue-7233
Domain: repo:objectui
File surface: objectui packages/app-shell/src/layout/InboxPopover.tsx, packages/app-shell/src/hooks/useHomeInbox.ts, tests alongside; i18n keys if a label is added
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: objectui#4071 (same package, HomePage) is MERGED — base is current main. #7266 (unclaimed finding) also names InboxPopover but is not in flight; its lines (:129/:137 hardcoded targets) are a different concern from the badge count and this card must not absorb them.

---

Generated by Claude Code

[os-zhuang]

ACCEPT — PR objectstack-ai/objectui#4073 (review by the epic PM session, verified against GitHub, not the report):

• Shipped: a breakdown line under the popover header — unclamped {total} total · {N} notifications + {M} pending approvals, rendered only when there is a badge to explain. Badge formula, counting APIs, and the badge's own 9+ clamp untouched (the ruling's minimal display shape). The approvals addend reads the same pendingApprovalsCount Home's card shows, closing the "8 vs 9+" reconciliation gap [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 measured.
• Two corrected facts, recorded in the PR body: the sum lives at InboxPopover.tsx:93 (not useHomeInbox.ts as the card said — that hook only sources one addend), and the "popover already sections the streams, per-section counts may suffice" hypothesis was falsified as sufficient: the existing tab pills clamp at 9+ too, so exact numbers — not sectioning — were the missing half.
• i18n: three new keys across all ten locale packs (all-locales-key-parity enforced it — an en+zh-only edit went red first, which is that gate working); named placeholders instead of {{count}} to avoid plural-key resolution the packs carry no forms for, with a 30-case placeholder pin.
• File surface: 14 files, all inside the claim; changeset present; [console] Four remaining inbox/activity entries still hardcode /apps/setup/..., so a business user without setup access has no working "all notifications" or "all activity" link #7266's hardcoded targets in the same file untouched as instructed. CI verified per-job: 20 check runs, Lint / Type Check / 4 test shards / Build & E2E all success, zero failures.
• Reverse verification in the predicted direction (4 red / 1 structurally-green, with the dev correctly noting the absence case is not evidence).

Next: PR flipped ready + queued. One doc-drift note for triage: en-zh-key-parity's docstring still claims the other eight packs are unasserted, which all-locales-key-parity has made stale — cosmetic, not filed as an issue by the dev; flagging here so triage can fold it into any i18n housekeeping card.

---

Generated by Claude Code