[approvals][console] Register an `approvals:inbox` component-registry key and de-hardcode the Approvals Inbox entry links

[os-zhuang]

Part of #7213 (entry convergence — see the triage comment there for the full plan and the boundary with objectui#2762 / objectui#2763).

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

• The Approvals Inbox page is apps/console/src/pages/system/ApprovalsInboxPage.tsx, routed as the relative route system/approvals inside the systemRoutes fragment (apps/console/src/AppContent.tsx:161-228), which is passed as BOTH extraRoutes and extraRoutesNoApp (AppContent.tsx:261). So /apps/{ANY_APP}/system/approvals already resolves — the page is not actually bound to the setup app.
• No navigation metadata anywhere points at the page. All entries are hardcoded:
  • packages/app-shell/src/console/home/HomePage.tsx:429 — onOpenApprovals={() => navigate('/apps/setup/system/approvals')} hardcodes setup; business users may lack access to the setup app;
  • packages/app-shell/src/layout/InboxPopover.tsx:117-121 already uses the current app prefix (correct);
  • server notification deep links use relative /system/approvals?request={id} and get app-prefixed by InboxPopover.tsx:157-158 (correct).
• The component registry (packages/app-shell/src/services/componentRegistry.ts; registrations in apps/console/src/registerDeveloperComponents.tsx:37-68 etc.) has NO approvals:* key (grep verified).

Scope

1. Register approvals:inbox in the component registry, resolving to ApprovalsInboxPage (follow the registerDeveloperComponents.tsx pattern; lazy-load like the route does). After this, a nav item { type: 'component', componentRef: 'approvals:inbox' } in any app renders the full inbox via the component/:ns/:name route (packages/app-shell/src/console/AppContent.tsx:790-791).
2. Fix HomePage.tsx:429 to navigate to the inbox under the current app (same approach as InboxPopover.tsx:117-121) instead of the hardcoded setup path.
3. Verify (and adjust if needed) that the page behaves correctly when mounted via the component route: useParams().appName for record deep links (ApprovalsInboxPage.tsx:461-464) and the ?request={id} deep-link drawer. The existing system/approvals route MUST stay — notification and email deep links depend on it; the component ref is additive.

Why a component ref (not a type: 'url' shortcut)

objectui#2763 (approved epic, on hold until after v17) will rebuild the approval surface on standard SDUI renderers and delete this bespoke page (its B3). The registry key is the stable indirection: the objectstack-side nav metadata (follow-up sub-issue of #7213, blocked by this one) points at approvals:inbox, and the v18 rebuild only repoints the key — zero nav-metadata churn.

Acceptance criteria

• approvals:inbox resolves in the component registry; /apps/{app}/component/approvals/inbox renders the inbox with working tabs, drawer, decision actions, and record deep links using {app}.
• The Home "pending approvals" card navigates within the current app (no hardcoded setup).
• /apps/{app}/system/approvals?request={id} still deep-links into the drawer.
• Tests updated/added where the touched code already has coverage.

Out of scope

Page polish (objectui#2762), SDUI rebuild (objectui#2763), bell-badge count breakdown (separate sub-issue), objectstack-side nav metadata (follow-up sub-issue).

[os-zhuang]

Claim: PM loop round 1 (maintainer-directed dispatch for #7213)
Session: session_01L9U1G2piXmYrhYQX96XUyv
Branch: claude/issue-7231-approvals-inbox-component-ref
Worktree: objectui-issue-7231
Domain: repo:objectui
File surface: objectui apps/console/src/ (component registration + AppContent wiring), packages/app-shell/src/console/home/HomePage.tsx, packages/app-shell/src/services/componentRegistry.ts consumers (read-only), tests alongside touched files
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: batch mate #7232 lands in objectstack (different repo). objectui#2762 (queued polish) scopes ApprovalsInboxPage internals, not the registry/HomePage; no open objectui PR touches these files per search at claim time.

---

Generated by Claude Code

[os-zhuang]

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

• Shipped: approvals:inbox registered in the component registry (new apps/console/src/registerApprovalsComponents.tsx, side-effect-imported from main.tsx); Home's pending-approvals card now resolves its target app (last-open app re-checked against the live active-app list → first active app → setup only for the degenerate no-segment case, with the zero-app unreachability pinned as a precondition test). ApprovalsInboxPage itself untouched (objectui#2763 boundary respected); the standalone system/approvals route and ?request= deep links preserved and pinned.
• File surface: 6 files, all inside the claim's declared surface; changeset present (app-shell + console patch); no releases/ADR paths.
• CI verified per-job: all 20 check runs completed — Lint success, Type Check success, 4/4 test shards success, Build & E2E success, changeset gates success; 2 skipped by design; zero failures.
• Notable: the dispatch's mechanism assumption about copying InboxPopover's app resolution was falsified by measurement (Home renders outside /apps/:appName/*) and the fix was reshaped accordingly — with reverse verification in the predicted direction. This is the process working as intended.
• Out-of-scope finding filed as [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 (four sibling /apps/setup/... hardcodes for inbox/activity), left unassigned for triage — deliberately NOT absorbed into the [approvals][console] 「待我审批」有三个并存入口、三套不同 UI —— 其中 sys_approval_request 原生视图是无决策动作的开发者原始表 #7213 epic (not required for its acceptance).

Next: PR flipped ready + queued for merge. #7234 (nav metadata, blocked by this) dispatches once it lands; a console pin bump chore follows per the standing linkage process.

---

Generated by Claude Code