✨ Adopt native multi-program QDMI jobs across Core and SDK plugins

[burgholzer]

🤖 AI text below 🤖

Elevator pitch

Submit an ordered program list through one QDMI job without making batching wait for the unsettled execution-capability model. SDK users should benefit where providers support the aggregate contract and keep concurrent single-program execution elsewhere.

Current state

QDMI #509 is now independently based on v1.4 and retains the existing program-format enum. Core #2373 extracts the low-level adoption from #2226 onto v4.1. Qiskit and PennyLane consumers remain separate follow-ups; #2349 independently improves concurrent single-program PennyLane submission.

Work and decisions

• QDMI #509 uses the existing program-format enum without a descriptor prerequisite.
• Review and land Core ✨ Adopt native multi-program QDMI jobs #2373: APIs, bindings, bundled-device support, and indexed results extracted from ✨ Adopt exact QDMI 1.4 payload contracts across Core #2226.
• Implement Qiskit and PennyLane consumers independently after the low-level contract is available.
• Validate the provider contract in IQM and Braket; support may remain single-program when aggregate semantics cannot be preserved.
• Preserve one shared optional shot setting, ordered result indices, aggregate lifecycle, and existing byte-exact submission. Atomic setter replacement does not imply atomic execution by remote hardware.

Dependencies and release boundary

Standard: Munich-Quantum-Software-Stack/QDMI#509. Core implementation: #2373; extraction source: #2226. Preserve concurrency work in #2349. Release coordination: #2093.

Acceptance and validation

• Each child has focused tests and can merge without payload-capability metadata.
• Native batches and concurrent single-program fallback produce the same ordered SDK results.
• A failed program, cancellation, retrieval, and unsupported cardinality have documented behavior.
• Core 4.1 and provider releases use released QDMI dependencies; development pins are not release pins.

Non-goals

New format descriptors; payload/classical capability design; arbitrary per-program options or partial-result semantics; simulated native batching that violates the provider contract.

Provider contract evidence

Before accepting QDMI #509, link a working Core consumer plus at least one existing provider demonstration; prefer both where applicable. The evidence must cover aggregate identity/lifecycle, indexed results, cancellation, failure, and retrieval—not just submission of a list. Providers without that contract retain concurrent single-program fallback. An SDK batch convenience API alone is not proof of a native aggregate job.

Sub-issues

• ✨ Extract QDMI multi-program Client and bundled-device support
• ✨ Use native QDMI multi-program jobs in Qiskit workflows
• ✨ Use native QDMI multi-program jobs in PennyLane workflows
• ✨ Adopt QDMI multi-program jobs for IQM
• ✨ Adopt QDMI multi-program jobs for Amazon Braket