Make QA-label apply non-blocking in /submit-for-review after merge

[sebastientaggart]

Make the post-merge QA-label apply in /submit-for-review non-blocking.

If gh issue edit --add-label "{{QA_READY_LABEL}}" fails (e.g. the label does not exist in the repo, or gh returns a non-zero exit), the prompt now instructs the LLM to print a one-line warning showing the stderr and continue to the resolution comment and success report — rather than aborting. The merge has already happened by that point; surfacing the failure is enough.

Source change is one sentence in skills/github-agile/submit-for-review.md; the four adapter outputs (.claude, .cursor, .agents, .gemini) are regenerated by ./sync.py --force.

A follow-up ticket (#183) was opened for the more durable fix: have /setup audit the configured labels once and offer to create any that are missing, so this failure mode is avoided entirely for projects that go through setup.

Closes #182

[sebastientaggart]

Review Summary

Verdict: APPROVE

Findings

• [NOTE] Source edit is a single sentence in skills/github-agile/submit-for-review.md (Step 9, post-merge QA-label block); the four regenerated adapter outputs (.claude, .cursor, .agents, .gemini) match the source verbatim with their template variable expanded, and the generated-by hash footers were updated as expected from ./sync.py.
• [NOTE] The new instruction lives inside the existing {{#if QA_READY_LABEL}} / {{#if BRANCH_DEV}} / {{#if !BRANCH_TEST}} guards, so behavior is unchanged for projects without a configured QA label or non-dev-merge flows.
• [NOTE] Non-blocking semantics are consistent with the PR description and submit-for-review should apply a configurable ready-for-qa label to the closed issue after merge #182 — the merge has already completed by the time the label-apply runs, so a warn-and-continue posture is appropriate, and Audit configured labels at /setup time and offer to create any missing ones #183 captures the durable setup-time fix.