[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

Found while implementing #7231 (PR objectstack-ai/objectui#4071). Filed rather than fixed there — #7231's scope is the approvals entry only.

The finding

#7231 fixed one producer that hardcoded the setup app in a navigation target. Four siblings with the same shape were left in place, all reached by the same non-admin users:

• packages/app-shell/src/console/home/HomePage.tsx:464 — onOpenNotification={(n) = > navigate(n.actionUrl || '/apps/setup/sys_inbox_message?view=mine')} (the fallback branch, taken whenever a notification carries no action_url)
• packages/app-shell/src/console/home/HomePage.tsx:472 — HomeActivity onViewAll → /apps/setup/sys_activity
• packages/app-shell/src/layout/InboxPopover.tsx:129 — goToAllNotifications → /apps/setup/sys_inbox_message?view=mine
• packages/app-shell/src/layout/InboxPopover.tsx:137 — goToAllActivity → /apps/setup/sys_activity

The last two are the notable pair: the same component's goToApprovals (line 119) and handleNotificationClick (line 142) already resolve currentAppName ?? params.appName and prefix with it. The two "see all" drills sitting between them do not — they were written as deliberate exceptions, and the comment above goToAllNotifications says why: "Route through the setup app's sys_inbox_message list view — the canonical full-page inbox (ADR-0030 L5), outside per-app sidebars."

Why it is still worth a look

That comment argues the OBJECT is app-independent, which is true, and then picks setup as the app to render it in, which does not follow — sys_inbox_message and sys_activity are framework-owned objects reachable at /apps/{any app}/{object} exactly like system/approvals was. A business user with no access to the setup app therefore has a dead "see all" on both the bell popover and Home, while the approvals row directly above it now works.

I did not verify the failure end-to-end in a browser against a non-admin session, so the user-visible symptom (shell "App not available" guard vs. something softer) is inferred from the routing, not measured.

Deliberately excluded from this report

/apps/setup/system/marketplace (HomePage.tsx:395, HomeAppsStrip onBrowseMarketplace) and /apps/setup/system/apps are admin-scoped surfaces where setup is a defensible target rather than an oversight. They are listed here only so a fix does not sweep them in without a decision.

Suggested shape

If it is taken up: the same resolution #7231 introduced in HomePage (last-open app re-checked against the live active-app list, then first active app, setup last) applied to all four, or — better, if the four are agreed to be one surface — a single shared helper the popover and Home both call, which the #7231 PR deliberately did not create because it was out of scope there.