feat(executors): add IonQ Direct executor

[Globalpropertyguy]

Closes #1. Replaces #7 after main was force-pushed/reset and the prior PR was closed without review.

Summary

• add IonQExecutor / IonQExecutorConfig for direct IonQ API submission
• convert Marqov circuits through to_qiskit() and QASM before submission
• map IonQ job results into ExecutionResult and backend availability into DeviceStatus
• register IonQ Direct in ExecutorFactory and export the executor API
• add mocked-client tests for submit/result/status/cancel/factory behavior

Verification

• /tmp/marqov-sdk-venv/bin/python -m ruff check marqov/executors/ionq.py marqov/executors/factory.py marqov/executors/__init__.py tests/test_ionq_executor.py
• targeted IonQ tests: 6 passed using explicit lightweight stubs for optional cloud/circuit SDK imports

Local environment note

• Full uv run --extra dev --extra all ... setup was blocked locally because llvmlite needed cmake, which is not installed on this machine. The failure is in Braket simulator dependency setup before these tests run, not in the IonQ executor code.

[ddri]

Thanks for the PR. I see you're a brand new account, making a number of PRs on projects in the unitaryHACK listing (and your Marqov submission were even before the event started!). The concern here would be that AI has done all the work, and there's not been any good-faith effort to really understand the project, make thoughtful decisions, and properly test the solution in context.

To help me understand if that's the case, I'd like to hear your thoughts on this, and talk a little about your experience and approach using the Marqov SDK.

[Globalpropertyguy]

Thanks for raising this here too. I understand the concern, especially because this is a new account and because both Marqov PRs landed around the unitaryHACK window.

I did use AI assistance while working on this PR, but I do not want to present it as a black-box submission that I cannot explain. My intent here was to implement the specific IonQ Direct executor requested in #1 while fitting it into Marqov's existing BaseExecutor and ExecutorFactory patterns.

My understanding of the Marqov SDK and this change is:

• Marqov already has a provider-neutral executor interface based around BaseExecutor.execute(...) -> ExecutionResult, plus cancel() and get_status() for job/device operations.
• The IonQ Direct executor should therefore return the same normalized ExecutionResult fields as the other executors: counts, backend, execution_time_ms, shots, raw result, and metadata.
• Since Marqov circuits already support conversion to Qiskit, I used that as the path to produce QASM rather than introducing another circuit serializer.
• I added a small REST client for IonQ v0.4 shape, but kept the executor injectable with a fake client so the behavior can be tested without live credentials.
• I mapped direct-IonQ job lifecycle behavior into the existing executor model: submit job, poll until success/failure, normalize counts/probabilities, support cancellation, and map backend availability to DeviceStatus.
• I registered "IonQ Direct" through the existing factory path rather than making callers instantiate the executor manually.

The main design choices I made were:

1. keep the provider-specific API code isolated in marqov/executors/ionq.py;
2. support client injection so tests do not require a real IonQ API key;
3. use QASM payloads because that is the least invasive route from Marqov's current circuit model;
4. normalize probabilities into counts when the result does not include counts directly;
5. avoid adding a new required SDK dependency for IonQ until the direct API behavior is settled.

For testing, I added focused tests for the deterministic parts: payload construction, QASM submission shape, counts/probability normalization, get_status() mapping, cancellation delegation, factory registration, and the IonQ v0.4 REST payload shape. Ruff passes for the touched files:

/tmp/marqov-sdk-venv/bin/python -m ruff check marqov/executors/ionq.py marqov/executors/factory.py marqov/executors/__init__.py tests/test_ionq_executor.py

I should also be clear about what I have not fully verified. I have not run this against a live IonQ account/API key, and a full local project install/test pass is blocked on this machine by the Braket/default-simulator dependency chain: llvmlite fails to build because cmake is not installed. So the verification I can honestly claim is focused/static/unit-level, not live-provider validation.

On the event timing: I was looking through listed repos before the event window and opened these Marqov PRs before appreciating that this could create a trust/eligibility issue. If that means this should not be considered for unitaryHACK credit, I understand. I am happy for it to be treated as a normal contribution, revised substantially, or withdrawn if that is better for the project.

If the direction is useful, I am happy to adjust the implementation to match your expectations. For example, I can:

1. change the payload shape if you prefer a different IonQ Direct API format;
2. require an official IonQ SDK instead of the small REST client;
3. remove compatibility branches for alternate client method names if they feel too speculative;
4. add more tests around polling, timeout, and failure states;
5. narrow the PR to only the pieces you consider mergeable.

I am happy to walk through or revise any part of it.