feat(triage): vet acceptance criteria before ready-for-dev

Problem

The reusable GitHub issue-triage extension can mark an issue ready after adding broad labels and a short checklist, without verifying that the acceptance criteria cover the behavior, repository constraints, and validation needed for a mergeable implementation. Its generated comment also lacks a clear boundary from the author's own issue text.

Desired Behavior

Issue triage should inspect the issue discussion and relevant repository guidance, improve incomplete criteria, and add ready-for-dev only after the resulting scope gives an autonomous developer and reviewer a high probability of producing a mergeable change. Agent-authored content must be visibly separated from human-authored content.

Acceptance Criteria

• Reuse the existing github-issue-triage extension and shared GitHub/conversation machinery; do not add a second triage implementation or extension-specific infrastructure.
• Evaluate each criterion for observability, completeness, consistency with repository guidance, and coverage of applicable compatibility, failure, lifecycle, security, documentation, and validation concerns.
• Inspect the issue body, subsequent human discussion, repository instructions, and the closest relevant implementation before finalizing criteria.
• Resolve reasonable ambiguity by proposing a bounded scope and explicit non-goals; withhold ready-for-dev only when a product or maintainer decision cannot be inferred safely.
• Post one concise triage comment after the existing discussion. Begin an agent-authored section with a clear delimiter and the exact sentence: “The following comments and acceptance criteria were added by the OpenHands AI agent.”
• Preserve the author's text and unrelated labels, replace stale automated triage output instead of accumulating duplicates, and verify the final comment and labels through GitHub.
• Add ready-for-dev only after the final criteria meet the standard above, so a PR that satisfies them and passes review is likely to be accepted.
• Add focused tests for prompt construction, deduplication, re-triage after human edits, and readiness behavior.
• Validate the extension on a fresh live issue through the OSS Agent Canvas automation and record the issue/conversation evidence in the PR.

Start by locating the existing github-issue-triage extension and its shared GitHub/conversation machinery, then review how prompt construction, deduplication, re-triage, and readiness are currently tested. Use the focused tests and a fresh live issue through OSS Agent Canvas to validate the final comment, preserved labels, readiness decision, and recorded issue/conversation evidence.