Engine-provisioned "Go to {objectLabelPlural}" command menu items resolve to the wrong object's label, and junction objects get non-functional ones

Environment: Self-hosted, v2.39.5

Background: Since #23795 (merged 2026-08-31), the metadata side-effect engine unconditionally provisions a "Go to {objectLabelPlural}" command-menu item (engineComponentKey: NAVIGATION) for every object, including junction/relation objects that have no navigable index page of their own.

Bug 1 — label collision: In a workspace with an object and its junction tables (e.g. Lead, plus junctions LeadContact, LeadOccupation, LeadAddress), the command menu shows multiple "Go to X" entries that all display the same resolved label instead of their own. Confirmed via direct DB inspection — 4 separate commandMenuItem rows exist, each with a distinct navigationTargetObjectMetadataId pointing at a different object (lead, leadContact, leadOccupation, leadAddress), all sharing the literal, unresolved label value "Go to {objectLabelPlural}". The frontend should interpolate each command's own target object's plural label independently, but instead all of them render as "Go to Leads." Reproduced in both a normal window and incognito, ruling out client-side cache — this points to a resolution/memoization bug keyed too broadly (likely on engineComponentKey alone rather than each command's own id or navigationTargetObjectMetadataId).

Bug 2 — non-functional for junction objects: Junction/relation objects have no sidebar entry or standalone index page in normal use. Their auto-provisioned "Go to X" command has nowhere sensible to navigate to, so clicking it does nothing.

To reproduce:

Create a custom object with at least one many-to-many relation (so a junction object is auto-created). Open the command menu (⌘K). Search for "Go to" — observe multiple entries with identical labels, one per junction plus the base object. Click one of the junction-targeting entries — nothing happens. Suggested fix directions:

Resolve each NAVIGATION command's label independently by its own navigationTargetObjectMetadataId, not a shared/memoized value. Consider whether junction objects (already excluded from normal navigation/sidebar) should get a NAVIGATION command provisioned at all, or should at least default isActive: false.