feat(core): add CDI policy resolver

[elezar]

Summary

Add a portable, fail-closed CDI context resolver that turns validated CDI specs into policy-relevant device, mount, and group requirements. This is the foundation of the stacked #1606 implementation.

Related Issue

Part of #1606.

Changes

• Add the shared CDI context schema and Linux-only resolver dependency boundary.
• Validate device-node types, paths, writable mounts, and supplemental GIDs.
• Add resolver unit coverage using temporary CDI specifications.

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (not applicable to this layer)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)

[drew]

Two fail-closed validation issues need correction before this layer merges. I reproduced the cache-refresh case with a focused openshell-core test: two conflicting specs defining the selected device currently return Ok.

[drew]

[P1] Fail on cache refresh errors before resolving selected devices. The pinned CDI cache can return an error while retaining a resolvable device (for example, two equal-priority specs defining nvidia.com/gpu=0). Because refresh_error is only consulted when lookup fails, this resolver accepts one ambiguous spec instead of failing closed; I reproduced this with two conflicting YAML specs and resolve_cdi_context returned Ok. Reject the refresh error here, or prove specifically that the selected device was unaffected, and add a duplicate-selected-device regression test.

[elezar]

The issue here is that the building the cache loads all CDI specs from the specified spec directories. These could include specs from different vendors or devices. Furthermore, if a spec fails to load (e.g due to malfomed YAML) there is no way to know which vendor or devices it was intended for.

This is the reason that we retain this information and include it if a device is unresolvable. This behaviour aligns with the behaviour for other CDI consumers including Docker, Podman, Containerd, Crio, and Kata.

I can add a test to prove that duplicate devices of the same priority causes a failure though.

[github-actions]

Label test:e2e applied for b65e4d8. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[github-actions]

Label test:e2e-gpu applied for b65e4d8. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute GPU E2E after building the required supervisor image once. The matching required CI gate status on this PR will flip green automatically once the run finishes.