pipeline: make agent-ready intake atomic and idempotent

[WalksWithASwagger]

Summary

Make the agent:ready intake transition atomic and idempotent so a valid issue cannot be falsely escalated while its dev loop starts.

Context

• Blocked by pipeline: disable retired Linear synchronization and remove its client #320 to serialize changes to the agentic workflows.
• Live evidence: skill: remove machine-specific paths from the real-sky upscaler #318 and build: align fresh-clone setup with the canonical verification gate #321 passed the local issue linter, then the dev loop added in-progress while another quality run fetched labels; the quality run reported Stop labels present: in-progress, removed agent:ready, and added needs-human.
• No pull request or remote branch was created for either issue; the provider was noop.
• Relevant files: .github/workflows/agentic-issue-quality.yml, .github/workflows/agentic-dev-loop.yml, scripts/agentic/issue_lint.py, scripts/agentic/dev_loop.py, and focused tests under tests/agentic/
• Desired behavior: one ready transition is quality-gated once before work starts, and temporary automation-owned in-progress state cannot invalidate that same intake.

Implementation Notes

• Treat this as workflow state-machine correctness, not a reason to weaken stop labels.
• Avoid running full issue-quality evaluation for unrelated label events merely because agent:ready is already present.
• Ensure the dev loop starts only after a successful quality result or performs the same validation before adding in-progress.
• Define the no-op result explicitly; a successful noop must clear temporary state without becoming a false human escalation.

Acceptance Criteria

• One agent:ready transition yields one authoritative quality decision before the dev loop marks work in progress.
• Adding or removing unrelated labels cannot re-lint a currently in-progress issue as a fresh ready intake.
• in-progress remains a stop label for independent intake attempts but does not invalidate the run that owns it.
• A successful noop run opens no PR, creates no remote branch, clears temporary state, and does not add needs-human.
• Invalid ready issues still lose ready aliases, gain needs-human, and receive a useful quality comment.
• Workflow concurrency prevents duplicate attempts for one issue without silently cancelling the authoritative result.
• Regression tests reproduce the skill: remove machine-specific paths from the real-sky upscaler #318/build: align fresh-clone setup with the canonical verification gate #321 event ordering and prove the false escalation is gone.

Tests/Evals

• Add workflow/event-matrix tests for ready, unrelated labeled, in-progress, invalid ready, noop success, and duplicate delivery.
• Use fixtures and mocked GitHub state; do not dispatch a live provider.

Verification

• python3 -m pytest tests/agentic -q
• npm test
• Parse both workflow YAML files.
• On a disposable test issue, add agent:ready once and confirm one quality outcome, one noop attempt, no PR/remote branch, no needs-human, and no lingering in-progress.

Agent Instructions

• Use branch codex/issue-<this-issue>-atomic-ready-intake.
• Do not start until pipeline: disable retired Linear synchronization and remove its client #320 is merged and main is green.
• Preserve sticky human stop labels and no-auto-merge behavior.
• Do not execute a command provider or use credentials beyond normal mocked/workflow tests.

Human Checkpoints

• Maintainer review is required before re-arming skill: remove machine-specific paths from the real-sky upscaler #318 or build: align fresh-clone setup with the canonical verification gate #321.
• The live disposable-issue proof must not invoke a provider or create a PR.

Out of Scope

• GitHub-only branch/PR traceability changes from pipeline: make branch and PR traceability GitHub-only #324.
• Provider selection or command-provider hardening.
• Branch protection, package work, or auto-merge.
• Implementing skill: remove machine-specific paths from the real-sky upscaler #318 or build: align fresh-clone setup with the canonical verification gate #321.

Linear

Not applicable. Rafiki delivery is GitHub-only; do not create or update a Linear issue.