Engine integration

The engine is a separate process with no database or storage credentials. Everything it needs (pending jobs, specimen downloads, training commands) and everything it produces (results, logs, labels, status) goes through the platform API using the engine's own API key. This keeps access control, auditing, and validation in one place.

1. A researcher or importer registers a sample; the platform creates an analysis job.
2. The engine asks for the next pending job; the platform hands out each job to exactly one worker.
3. The engine downloads the specimen through a short-lived URL and runs static analysis and, where enabled, sandbox execution.
4. The engine posts a structured report (verdict, score, indicators, raw report).
5. The platform stores the report, updates the sample status, and records an audit entry.

The engine reports its state (idle, busy, or offline) with a regular heartbeat. The platform treats a missing heartbeat as offline, which feeds the workspace dashboard and, later, the public status indicator.

Model training is started, paused, resumed, or stopped from the workspace. The platform queues a training command; the engine polls for the next command, runs it, and reports progress through logs and experiment runs.

The engine's API client and the shared OpenAPI contract are being reconciled: several engine calls (log upload, labelling, VirusShare import state) are not yet in the contract, and report field names differ. The contract in shared/openapi.yaml is the source of truth; the engine and platform will both be brought in line with it before the /api/v1 routes go live.