Org and cluster card menu targets are relative, so they can re-resolve one segment too deep (same class as #1710)

## Summary

#1710 fixes the instance rows, whose relative `../instance/` targets re-resolved against the
current location and produced `/{org}/{cluster}/instance/instance/`. The org and cluster cards
build their menu targets the same way, one layer up:

- `src/features/organizations/components/OrgCard.tsx:48` — `to: \`${organizationId}\``
- `src/features/clusters/components/ClusterCard.tsx:200` — `to: \`${cluster.id}/sign-in\``

Both are bare relative segments. A card that outlives a pending navigation re-resolves its target
against the new location, so `${cluster.id}/sign-in` clicked from `/org-a` after the route has
already moved to `/org-a/clu-b` yields `/org-a/clu-b/clu-b/sign-in`.

## Why this is separate from #1710, and low priority

**RUM shows zero occurrences in the last 30 days** (`@view.url_hash:*clu-*/clu-*`), against 47 views
and 10 sessions for the instance-row variant in the same window. The class is present in the code
but the timing window evidently is not being hit here — likely because the cards unmount with their
list rather than surviving the transition the way a table row does.

Worth closing anyway so the pattern does not reappear, and so
`EntityMenuItem.to`'s contract can be tightened to absolute-only.

## Fix

Same shape as #1710: build the targets with `buildAbsoluteLinkToPage` instead of a relative segment.

Start with the menu target definitions in src/features/organizations/components/OrgCard.tsx:48 and src/features/clusters/components/ClusterCard.tsx:200, then compare the corresponding fix in #1710. Update both targets to use buildAbsoluteLinkToPage and verify that they no longer contain bare relative segments, preserving the intended organization and cluster sign-in destinations.

Written by the indexing model from the issue text.