fix(nav): stop the sidebar promising two pages that are not built, and surface one that is

[0xmanhnv]

Two problems on the same screen, in opposite directions.

The sidebar promises two things it does not have

/settings/integrations/cicd and /settings/integrations/siem render
ComingSoonPage — 20 lines each. Nothing in the nav distinguishes them from the
live integrations sitting beside them, so the click is a dead end.

They now carry a Soon badge. The mechanism already existed —
getBadgeValue(dynamicBadges, url, item.badge) falls back to a static
item.badge, and badge?: string is already on the nav item type. It had simply
never been used.

Badged rather than deleted, deliberately. The entries communicate roadmap,
which is worth keeping. What is not worth keeping is a nav item that looks
shipped.

And it hides one it does have

/settings/integrations/api-keys is 501 lines, wired to /api/v1/api-keys —
list, create, revoke, delete — and has no navigation reference anywhere:

• not in sidebar-data.ts
• not among the cards on the integrations landing page
• not linked from any other page

The only mentions of api-keys in the tree are the feature's own hooks and types,
consumed by the MCP page (which uses the hook, not the route). A working feature
nobody can reach. It is now a card alongside the other integration categories.

Scope — this is the confirmed subset, not a sweep

107 pages are absent from the sidebar. That number is real but not a list of
orphans: most are reached as tabs or sub-pages.

This codebase navigates through config objects — router.push(category.href),
router.push(`/assets/${listingSlug}`) — so grep cannot answer "is this page
reachable". Every automated pass I wrote produced a different number, and each
was wrong in a different way:

Attempt	Result	Why it was wrong
literal reference search	107 "orphans"	used grep -F with an alternation, so the | was matched literally
final-segment search	54	common words (secrets, tickets, trends) match anything
navigation-context regex	45	misses `/assets/${slug}` — dynamic hrefs
+ landing-page check	2	misses router.push(category.href) — href via variable

api-keys is the one that survived every pass and a hand read of the landing
page. That is why it is the only route this PR wires up.

Deciding the fate of the remaining pages — wire or delete — needs a product call
per cluster, not a regex.

Verification

tsc --noEmit clean, eslint clean on both changed files, prettier-formatted.