feat(security-issue-sync): auto-propose backtick-wrap for Affected versions field

[potiuk]

Summary

The Affected versions body field on tracker issues holds version expressions like >= 3.0.0, < 3.2.2. Without surrounding backticks the leading > is interpreted by GitHub as a markdown blockquote, so the rendered field shows as a quoted single line. Maintainers editing via the issue-form UI then see the visible (un-quoted) text and "fix" it by removing the >= prefix, silently turning a bounded range into a misleading single-version entry like 3.2.1 — and the CVE record that follows publishes with the wrong affected range.

This was observed in the wild during the 2026-05-28 bulk sync against airflow-s/airflow-s: multiple trackers had their Affected versions field re-rendered as a blockquote, then edited down to a bare single version, then regenerated into CVE JSON with { "version": "3.2.1" } — instead of { "lessThan": "3.2.2", "version": "3.0.0", "versionType": "semver" }.

Changes

Two complementary additions to security-issue-sync:

1. Step 1d signal table — add a row for "Affected versions field has a value but it is not backtick-wrapped" so sync surfaces and auto-proposes the wrap on every run that finds one, even when no other body update is being proposed for the tracker.

2. Step 2b body-field emitter — add a sentence to the "Affected versions" derivation rule reminding the emitter to wrap the proposed value in backticks, with a cross-reference to the new signal row for the underlying reason.

The generate-cve-json parser already strips backticks at parse time (cleaned = value.strip().strip("\").strip()—cve_json.py:651`), so this is a pure-cosmetic + edit-resilience fix with no semantic change to existing trackers or CVE JSON output. The fail-loud parser introduced in #362 continues to refuse genuinely un-parseable input; this PR makes the input less likely to drift into that state.

Test plan

• Skill markdown lints (no new tools / capabilities / yaml schema changes, so skill-and-tool-validate is the only relevant hook).
• No code change to the generator → existing parser tests unchanged.
• Manual end-to-end: next /security-issue-sync invocation against a tracker with an un-wrapped Affected versions value should surface the wrap as a proposed body-field change (verified out-of-band when this lands).

Follow-up

The issue template (.github/ISSUE_TEMPLATE/...) lives in the adopter repo, not in airflow-steward. A companion PR against airflow-s/airflow-s will update the template's placeholder example and add an inline note to the field description so reporters and triagers start the value in the right shape.

Was generative AI tooling used to co-author this PR?

• Yes — Claude Opus 4.7 (1M context)