permissionKey cannot express an OR of keys, so multi-key affordances cannot adopt PermissionShield #1747

Description

permissionKey accepts exactly one Key, and every permission-aware component treats it as the whole authorization decision:

const useHasPermission = (key?: Key) => {
  const ctx = usePermission();
  return !key || !ctx ? true : ctx.userHasPermission(key);
};

NavigationNavbar additionally drops the legacy permission boolean once a key is present:

<MenuItem disabled={hasKey ? undefined : !permission} permissionKey={item.permissionKey} … />

So an affordance that is legitimately gated on more than one key cannot adopt the declarative path at all - supplying either key alone narrows access, and supplying none forfeits the shield.

Concrete case

layer5io/meshery-cloud's Identity → Organizations nav item:

permission:
  canKey(Keys.IdentityAccessManagementViewAllOrganizations) ||
  canKey(Keys.IdentityAccessManagementViewOrg),

A provider admin holds View All Organizations; an org member holds View Org. Passing permissionKey: Keys.IdentityAccessManagementViewOrg would hide the item from provider admins who only hold the former, and vice versa. That item is consequently the one entry left on the legacy boolean path in layer5io/meshery-cloud#5757, so it renders no PermissionShield and gives the user no explanation when access is blocked.

Proposed fix

Let permissionKey accept a set with an explicit combinator, defaulting to the current single-key behaviour:

permissionKey?: Key | { anyOf: Key[] } | { allOf: Key[] };

useHasPermission resolves anyOf with .some(...) and allOf with .every(...). PermissionShield can list every unmet key in its tooltip, which is strictly more useful than the single-key rendering.

This is backwards compatible: a bare Key keeps working unchanged.