✨ Use native QDMI multi-program jobs in Qiskit workflows

🤖 AI text below 🤖

Elevator pitch

Qiskit circuits and primitive workloads should use provider-native batches when supported, with stable result ordering and a reliable concurrent single-program fallback.

Current state

python/mqt/core/plugins/qiskit/backend.py currently serializes each circuit and calls submit_job separately; the job wrapper represents multiple individual handles.

Work and decisions

• Consume the low-level multi-program API once available. Validate and serialize inputs before submission.
• Group only programs sharing the format and job-level options/shot setting. Preserve original circuit and primitive result ordering.
• Probe supported cardinality without submitting paid work. Fall back only for unsupported batching, not after authentication failures or ambiguous submission errors.
• Decode indexed results and adapt the existing job wrapper rather than inventing a second SDK job hierarchy.
• Cover backend.run, SamplerV2, and EstimatorV2 paths that use the adapter.

Dependencies and release boundary

Parent: ✨ Adopt native multi-program QDMI jobs across Core and SDK plugins. Requires ✨ Extract QDMI multi-program Client and bundled-device support. Coordinate with provider children; do not wait for payload metadata.

Acceptance and validation

• Deterministic fake-device tests cover native batches, single-program fallback, mixed options, indexed results, cancel/wait/failure, and output order.
• Both primitives return the same shapes and values as the fallback.
• No retry causes duplicate remote submissions after an uncertain failure.
• Run focused Qiskit tests and supported/minimum Python sessions plus full lint.

Non-goals

Implicit transpilation; changing payload capability semantics; new provider dependencies; batching heterogeneous jobs into a contract that only accepts homogeneous lists.

Provider compatibility evidence

Contribute an end-to-end example to #2359 using the matching provider implementation. Verify ordered SDK results and lifecycle behavior for both supported native batches and concurrent single-program fallback. Do not infer aggregate support from a provider SDK's batch convenience API.