test(tmachine): add hardware-free Docker CDI qualification #4460

User Story

As an OpenShell contributor, I need to test Docker CDI device injection in tmachine without GPU hardware, so I can validate explicit and count-based device selection in the integration suite.

Description

Add hardware-free CDI fixtures to the Docker tmachine environment and a feature suite that verifies injected environment variables and file mounts. Provide local Debian artifact generation so the suite can exercise OpenShell's DEB installation path using binaries built from the checkout.

Context

The initial scope is Docker only. Fixtures use YAML CDI specs with ordinary workload environment names and file mounts; they do not require device nodes or GPU hardware. Runtime behavior and the reserved OpenShell environment namespace remain unchanged.

Definition of Done

• Docker environment setup supplies dummy YAML CDI specs in /var/run/cdi on every VM boot.
• Feature tests cover no GPU request, explicit single and multiple devices, default and count-based selection, unavailable counts, unknown devices, and device/count mismatches.
• A binaries task builds the DEB inputs, including the prover and embedded VM driver; a separate DEB task only packages staged binaries.
• The suite passes using the tmachine DEB installer and is included in branch and release feature-test matrices.
• Local build and test commands are documented.

Follow-up Coverage: CDI Policy Resolution

The fixture and test infrastructure in #4461 should support hardware-free integration coverage for the CDI policy-resolution work in #4204. The checks below are follow-up requirements; they are not claims about coverage already supplied by #4461. Exercise the production resolver and real Docker mounts rather than relying only on spec-hint baselines, synthetic mountinfo, or constructed inspection JSON.

Acceptance Criteria

• Exercise actual read-only and read-write file mounts with omitted access flags, bind/rbind, and explicit flags. Classification follows effective workload mount flags. An effectively read-only target needs no writable-policy opt-in; an effectively writable target must be a regular file with an exact authored read_write entry. Missing opt-in, ancestor-only opt-in, and writable directory destinations are rejected.
• Exercise real directory bind mounts with read-only children and with writable submounts beneath a read-only parent, including recursive binds and bind aliases. Writable submounts are detected and the directory destination is rejected; a fully read-only directory is accepted. Expanded shared-library parents are not mistaken for original directory mounts.
• Verify legitimate shared-library directory symlinks are accepted, aliases to forbidden broad roots are rejected, and a controlled path replacement between resolution and enforcement cannot cause Landlock to grant access to an unvalidated object.
• Use actual Docker inspection results to verify that the expected CDI spec projections are admitted with default resource admission enabled. Changed source, destination, type, access or propagation; missing or duplicate projections; and unrelated bind mounts are rejected. The suite does not disable admission to make CDI tests pass.
• Exercise initial workload launch and subsequent piped and PTY execs. Each applies the same CDI requirements and repeats descriptor validation, including rejection after a target's type or effective access changes. CDI does not add a blanket /proc write grant or override authored /proc policy.
• Verify supplemental groups using dummy CDI additionalGids: runtime-supplied groups satisfy the existing membership check, while missing required groups produce a clear launch failure. Tests do not require OpenShell to inject groups or add GroupAdd handling.
• Run a large synthetic spec through the production enforcement path and verify that the number of simultaneously open CDI target descriptors stays bounded as the number of mount destinations increases.
• Include the additional cases in the tmachine Docker CDI qualification lane and document local execution and fixture requirements. Fixtures use ordinary files, safe existing devices where needed, and non-reserved environment names; no NVIDIA GPU or CUDA workload is required.

Scope and Tracking

Actual NVIDIA runtime/toolkit compatibility and CUDA execution remain separate hardware-validation work. The broader audit of non-CDI path opening and driver-side CDI mount placement is outside these coverage requirements.

#4461 references this issue without closing it. Keep this issue open until the follow-up coverage criteria are complete; the initial fixture PR does not complete the follow-up checklist.