✨ Add a reusable QDMI device access and status checker

🤖 AI text below 🤖

Lead: @flowerthrower. Cross-repository coordination: @burgholzer.

Elevator pitch

Optional launch-time validation should reuse Core’s existing session-open and device-status semantics instead of embedding each provider in a scheduler plugin.

Current state

src/qdmi/Slurm.cpp opens the registered device through Core and accepts IDLE or BUSY. Other statuses and session errors fail. This works with released QDMI 1.3.x and is weaker than a promise of immediate execution.

Work and decisions

• Expose a small MIT command-line check using the same shared open/status behavior; do not duplicate provider-status interpretation.
• Separate explicit device selection from Slurm parsing so the executable itself need not link Slurm or provider SDKs directly.
• Specify stable result diagnostics/exit codes and bounded execution.
• Use the effective job catalogue, provider configuration, and ordinary credential chain.
• Do not query a proposed accepting-jobs property or claim authorization/availability for another identity.
• Keep the checker optional and independent of the scheduler design.

Dependencies and release boundary

Parent: ✨ Centralize static-license QDMI deployment and optional SPANK injection. Consumer: ✨ Add optional generic SPANK launch-time device validation. Later availability design is 💡 Design QDMI availability-based Slurm scheduling and is not a prerequisite.

Acceptance and validation

• Fixtures cover IDLE, BUSY, other statuses, unknown device, authentication/provider failure, timeout, and cleanup.
• No Slurm/GPL dependency enters the MIT executable/package.
• The job-context integration proves that checker and payload see the intended same configuration, without service credential inheritance.
• Target Core 4.1/MQSF with the shared setup and provider migrations. Include only if the safety tests pass; otherwise defer without blocking static migration.

Non-goals

Availability-based admission; QDMI #522; guaranteed task acceptance or execution time; embedding provider libraries in SPANK.

Shared validation fixture

Exercise the checker/plugin boundary in Core's common Dockerized Slurm fixture with provider configuration supplied by the integration tests. Reuse the existing open and IDLE/BUSY semantics; successful validation is not a promise of submission acceptance or prompt execution.