Client run submits a task before rejecting nonpositive wait controls

Start with the standalone artemis-client implementations of run(), run_task(), and wait_for_task(), following where timeout and poll_interval are validated relative to submit(). Add regression coverage using the injected transport interface to verify invalid controls make no transport calls through both entry points, while valid submit-and-complete behavior remains unchanged.

At 371aa6df56880643da57b30da936e9812fb0ec66, the standalone artemis-client package submits a task before rejecting a nonpositive timeout or poll_interval passed to run(); run_task() inherits the same behavior. The caller receives ValueError without a task handle, although a real server may already have started the submitted work.

run() awaits submit() before calling wait_for_task(), where those arguments are validated. Direct wait_for_task() already rejects them without a transport request. Expected: reuse those checks before task submission, keeping valid calls unchanged.

Credential-free reproduction using the package's injected transport interface (no server or device needed):

import asyncio
from artemis_client import ArtemisClient

class RecordingTransport:
    def __init__(self):
        self.calls = []

    def request(self, method, path, *, json_body=None):
        self.calls.append((method, path))
        return {"status": "started", "tasks": [{
            "session_id": "00000000-0000-4000-8000-000000000123",
            "status": "pending",
        }]}

async def main():
    transport = RecordingTransport()
    client = ArtemisClient("https://artemis.example.test", transport=transport)
    try:
        await client.run("Open Settings", timeout=0)
    except ValueError as error:
        print(type(error).__name__, str(error))
    print(transport.calls)

asyncio.run(main())

Observed with Python 3.12 and the package source on PYTHONPATH:

ValueError timeout must be greater than zero
[('POST', '/api/run')]

Expected transport calls: []. Zero/negative values for both controls reproduce this through both run() and run_task(); a valid submit-and-complete control still succeeds. I have prepared a small fix with regression coverage and am checking contribution requirements before submitting the patch. I found no matching open issue or PR in the current inventory.