🔧 Harden installed QDMI runtime staging

[burgholzer]

🤖 AI text below 🤖

Description

Stage the complete QDMI runtime closure for installed and imported consumers.

This pull request:

• stages imported MQT::CoreQDMI, MQT::CoreQDMIDriver, and device libraries through mqt_copy_qdmi_runtime;
• copies transitive runtime DLLs on Windows;
• preserves device manifests, provider assets, and build RPATHs;
• installs the public qdmi/ProgramFormat.hpp header required by qdmi/Client.hpp; and
• validates the installed package through a real find_package(mqt-core) consumer that creates a qdmi::Session.

The change only hardens deployment. It does not add another Client or Driver API.

Dependencies

This PR is stacked directly on #2230.

Validation

On the exact replay:

• focused Driver build: passed;
• installed-consumer fixture: 2/2 passed;
• Driver tests: 97/97 passed;
• full repository lint: passed;
• signed commit verification and diff checks: passed.

The preceding deployment layer also passed the full 440-step release build and documentation build. The imported-target closure passed simulated Windows generation with CMake 3.28 and 4.4.

Hosted CI is pending for this draft.

AI assistance: OpenAI Codex assisted with implementation, review, testing, and this description.

Checklist

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

If PR contains AI-assisted content:

• Any agent that created, edited, or submitted GitHub content was explicitly authorized for that scope, as required by our AI Usage Guidelines.
• Every agent-authored or agent-edited public text body begins with the visible disclosure 🤖 *AI text below* 🤖 (titles are exempt).
• I have disclosed AI assistance in the PR description.
• I confirm that I have personally reviewed and understood all AI-generated content, and accept full responsibility for it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[burgholzer]

Also quite a bit of meta comments here for the general direction of this series. This should complete the run of feedback through the PRs.

[burgholzer]

This feels overly complicated and slightly confusing, especially because of the terminology being used. "closure", "staging", "concrete", "runtime".
I think this is important work to ensure a robust installation and usage; but it needs to be prepared in a better fashion.

Our top distribution channel is the mqt-core Python package. It is either directly used, which needs to work with the shipped libraries. Or it is loaded in other Python-only libraries (also not critical), or it is used to feed a find_package(mqt-core) call in another project (such as MQT QCEC, MQT DDSIM, or MQT QMAP). The latter case is probably the one that is hardest to get right across all systems when it comes to using the QDMI-related functionality.
However, I still have the feeling that most of that was already working quite alright.

The second distribution channel is likely installations in HPC centers. These would typically build MQT Core from source via tools like spack. I do not really foresee major problems there with the solution that we previously had in place (maybe I am missing something though). The key aspect here is that this is almost exclusively for Linux (x86 and arm64), while the Python distribution channel is much broader and needs to cover macOS and Windows.

Maybe one can simplify around that information and already include these thoughts in the iteration on the lower layers.

[burgholzer]

This definitely goes out of its way to prove that something works.
I'd personally be fine if this was demonstrated locally but not directly included in the test suite.