fix: every queue_agent call creates a permanent jobs_v2 row with no cleanup path

[sam-saffron-jarvis]

What changed

• Tagged queue_agent-created jobs with a dedicated labels marker so the jobs server can distinguish ephemeral sub-agent jobs from normal user-managed jobs.
• Extended jobsV2Manager.pruneOldData to delete old terminal queue_agent jobs from jobs_v2 itself before the existing run/event retention pass.
  • This only applies to jobs carrying the queue-agent ephemeral label.
  • Jobs are deleted only when they have no active/non-terminal runs and their latest run activity is older than the existing run-retention cutoff.
  • Old untriggered queue-agent jobs are also cleaned up once they age past that cutoff.
• Added tests covering:
  • queue_agent sending the ephemeral labels marker on job creation.
  • retention pruning deleting old queue-agent jobs while preserving recent queue-agent jobs, active queue-agent jobs, and normal manual jobs.

Why this is high-value

Every queue_agent call previously inserted a brand-new permanent row into jobs_v2 and nothing ever removed it. Over time that makes the jobs catalog grow without bound, which directly increases the amount of persistent state behind:

• SELECT COUNT(1) FROM jobs_v2
• paged /v2/jobs reads
• admin/job-list clutter

This fix turns that permanent leak into bounded retained state. After the normal run-retention window passes, old ephemeral queue-agent jobs are deleted entirely, so the job catalog no longer grows forever from one-shot background sub-agent work.

Validation

• gofmt -w internal/tools/queue_agent.go internal/tools/queue_agent_test.go cmd/serve_jobs_v2.go cmd/serve_jobs_v2_test.go
• go build ./...
• go test ./...
• git diff --check

[SamSaffron]

Closing as requested: the high-confidence fixes have been applied or superseded in the current working tree.