📝 Document the canonical static-license QDMI deployment

🤖 AI text below 🤖

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

Elevator pitch

Administrators and application authors need one tested guide that distinguishes runtime deployment, catalogue selection, scheduler accounting, optional injection, and provider authorization.

Current state

docs/qdmi/slurm.md and test/slurm already provide the baseline. Provider guides currently duplicate setup and can lead users to install two device runtimes unnecessarily.

Work and decisions

• Make docs/qdmi/slurm.md the authoritative operations guide with provider pages linking it.
• Explain shared environments, per-node installs, native catalogues, and wheel catalogues as explicit alternatives.
• Show static licenses without SPANK, optional configuration injection, and the optional access/status check separately.
• Demonstrate Qiskit and PennyLane construction from the selected handle.
• Explain that environment-based selection is not allocation attestation or provider authorization.
• Keep credentials in the normal provider chain; document path/identity troubleshooting without secret examples.
• Put future availability-based scheduling in its design tracker rather than production instructions.

Dependencies and release boundary

Parent: ✨ Centralize static-license QDMI deployment and optional SPANK injection. Shared component: ✨ Add shared source-only SPANK configuration injection. Optional check: ✨ Add a reusable QDMI device access and status checker / ✨ Add optional generic SPANK launch-time device validation.

Acceptance and validation

• Test documented commands against the Slurm fixture and both provider integrations.
• No instructions require a second runtime for every Python workload.
• Failure troubleshooting identifies selection, loading, authentication, status, and submission separately.
• uvx nox --non-interactive -s docs and documentation link checks pass.
• Target Core 4.1/MQSF with the shared setup and provider migrations.

Non-goals

A second generic guide in each provider repository; speculative scheduler policies documented as shipping features.

Documentation boundaries

Use Core's shared Dockerized fixture for executable examples and reference the same setup from both provider guides. Present static-license selection, optional configuration injection, optional launch checks, catalogue/runtime deployment, and provider authorization separately. General QDMI architecture and onboarding belong to QDMI #527, not a second scheduler guide.