genpolicy: namespace comparison is order-sensitive and denies identical namespace sets

Description

allow_linux compares the policy's normalized namespaces against the CreateContainerRequest's with ==:

https://github.com/kata-containers/kata-containers/blob/5752e890a/src/tools/genpolicy/rules.rego#L621

Both sides are built with array comprehensions, and == on Rego arrays is order-sensitive. The runtime is free to hand the agent the same namespaces in a different order than genpolicy recorded them when it generated the policy. When it does, the container is denied even though the two sides hold exactly the same namespaces.

Impact

The denial doesn't correspond to anything in the pod spec, so it reads as a spurious policy failure rather than a real mismatch. It tracks the containerd/runc version rather than the workload, so it can appear after a node upgrade or on one cluster but not another with the same manifests.

Reproduction

Reordering two namespaces in the request is enough. Adding this case to src/tools/genpolicy/tests/policy/testdata/createcontainer/network_namespace/testcases.json:

{
  "description": "namespaces in a different order than the policy",
  "base": "create-container",
  "allowed": true,
  "patch": [
    { "op": "move", "from": "/OCI/Linux/Namespaces/1", "path": "/OCI/Linux/Namespaces/0" }
  ]
}

fails on main:

== case: namespaces in a different order than the policy ==
assertion `left == right` failed
{"kind":"CreateContainerRequest","request":{"allowed":true,...}}
{"kind":"CreateContainerRequest","request":{"allowed":true,"ops":[]}}

Suggested fix

Sort both sides before the comparison. Sorting rather than converting to sets keeps duplicate entries significant, so apart from the ordering requirement the check stays as it is. sort is registered unconditionally in the regorus aggregates builtins, so it is unaffected by the trimmed feature list in src/agent/policy/Cargo.toml.

I have the change and the test ready and will open a PR against this issue.