feat(dgw): run AI analysis of a recording as a provisioner task

[irvingouj@Devolutions (irvingoujAtDevolution)]

AI analysis of a recording, started by DVLS with a plain HTTP request (no new token type), tracked as a provisioner Task and run as a job on the existing job queue.

Provisioner tasks run through a ProvisionerTaskRunner, the one place that keeps a task's record (#2041's ProvisionerTaskRecord) and its job in step. Each kind of work is a ProvisionerTask (what one attempt does, what to drop once its record ends); the runner creates the record, queues its job, runs each attempt with its timeout, retries transient failures and records how the Task ends. The Task is the source of truth and the job only wakes it up: each Task names the one job allowed to run it (#2041), so a stale or duplicate job does nothing. A Task is reported created only once its job is stored in the job queue. At startup, before the job runner claims anything, an unfinished Task whose job is no longer stored (such as after a crash between recording the Task and storing its job) gets a new one; a Task whose job is still stored keeps it. The analysis itself is the AI crate's analyze_recording (#2043); Gateway hands it the manifest of the finished recording and adds the log it returns to the session.

API (stable, no enable_unstable)

• POST /jet/jrec/{session_id}/ai-analysis, scope gateway.tasks.recording-ai-analysis.start. Body: taskId, provider, model, baseUrl (needed for openai-compatible), maxOutputTokens, apiKey.
  • 202 + Task when created, 200 + Task for the same request again
  • 400 bad settings or body, 404 no recording
  • 409 task_id_conflict / recording_active / analysis_in_progress (+ the running taskId)
• GET /jet/jrec/{session_id}/ai-analysis/{task_id}, scope gateway.tasks.recording-ai-analysis.read: the Task (state, payload, attempts, times), or 404. The 202 answer of the POST names it in its Location header. A Task of another kind, or the analysis of another session, is not found under that path.

Each provisioner task declares its own scopes, gateway.tasks.<kind>.start and gateway.tasks.<kind>.read, so a token for one kind of Task can neither start nor read another kind. The kind of AI analysis is recording-ai-analysis.

The two new scopes in Devolutions.Gateway.Utils and the regenerated OpenAPI clients are in #2054, stacked on this PR.

The first commit hands the provisioner task store (#2041) to DgwState on its own gateway.db connection; DgwState::mock becomes async for that, hence the .await in a few tests. It also passes job_queue::MAX_ATTEMPTS (5, same as the current default) to the job queue explicitly, so the retry check in the AI analysis job can't drift from it.

How it behaves

• The API key and base URL live in memory only, encrypted, as the Task's secret in the provisioning store (feat(dgw): keep provisioner task secrets in the provisioning store #2058); never in the job, gateway.db or our logs. After a Gateway restart the Task fails with "the API key is no longer available".
• Transient provider errors are retried by the job queue (up to 5 attempts); permanent ones fail the Task. 30 min per attempt, 2 h per Task.
• Terminal (.cast, .trp) and video (.webm) recordings are analyzed (feat(dgw): analyze any recording in the AI crate #2043); video needs XMF v2026.9.25.0 or later. The result is a new ai-analysis-N.slog in the session's artifacts, and the Task payload says which file, the model, the prompt versions and the token usage.

Where to look hardest

• provisioner_tasks/runner/mod.rs: run_attempt (cancel on timeout, retry vs. fail, on_end on every end) and resume (called from service.rs before the job runner starts)
• provisioner_tasks/recording_ai_analysis/mod.rs: the AI ProvisionerTask, and lock_session: the working files belong to the session, so analyses of one session run one at a time (a Task past its deadline may still have an attempt running when the next Task starts)
• start() in the same file: the order of the checks

Known, accepted

• At VerbosityProfile All, reqwest/hyper's own TRACE lines show the provider's address (not the key). Our code never logs it.
• If Gateway crashes right between adding the artifact and moving the .slog in, the manifest can point at an empty file. Closing that needs a change to add_artifact.

Tested: devolutions-gateway lib 218 (incl. the runner against a test task: stale jobs after resume, a job that cannot be queued, panics, invalid parameters and unknown kinds; and the AI analysis job against a mock provider: retry resumes at the first chunk left, permanent and exhausted errors, timeout, deadline, lost key, one analysis per session, leftover files removed), tests/ai_analysis.rs 8/8. End to end on the real Gateway binary (127.0.0.1), before the move to ProvisionerTaskRunner and not re-run since with XMF and GPT-6 Luna on a real WebM session: POST → the first attempt hit a connection reset and was retried 30 s later, resuming from the saved screenshots → succeeded, ai-analysis-0.slog in the manifest, working files gone, the API key nowhere in Gateway's logs or data folder.

🤖 Generated with Claude Code

[github-actions]

Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries