QueueRow.payload doc comment claims worktree_path and prompt_file, which it does not carry

[rdfitted]

Follow-up from #268 (PR #275). Found during T8 reconnaissance and independently confirmed.

The problem

QueueRow.payload's doc comment at src-tauri/src/storage/queue.rs:79-81 describes the blob as:

Full spawn context (worktree_path, prompt_file, wsl-converted path, model, parent_id) so a claim at a later time has everything it needs — addresses the stale-path risk.

The production payload is constructed at src-tauri/src/http/handlers/workers.rs:508-516 and actually contains:

role_type, cli, model, flags, parent_id, initial_task, task_id

No worktree_path. No prompt_file. Those artifacts are created later inside add_worker_for_plan_task, after the queue claim.

Why this matters

The comment states the exact rationale — "so a claim at a later time has everything it needs — addresses the stale-path risk" — which is the kind of claim someone will rely on when reasoning about crash recovery or slot reuse. It asserts a durability property the data does not have.

It already misled work once: the #268 plan's evidence section repeated the comment verbatim as established fact, and a worker had to discover the discrepancy by reading the construction site.

Suggested fix

Either:

• Correct the comment to describe the real contents and say plainly that worktree/prompt paths are materialised after the claim, not before; or
• Decide the comment was aspirational and the behaviour is the bug — i.e. the payload genuinely should carry the spawn paths for stale-path safety — and file that as the real work.

These are different fixes with different risk. Worth a moment's thought about which was originally intended rather than defaulting to editing the comment.

Note

payload is free-form serde_json::Value, so #274 was able to add executed_as to it with no schema migration. That remains true either way.