fix(generate-cve-json): forward-state labels keep CNA_private.state at REVIEW

[potiuk]

Summary

When release-vote gating is enabled ([workflow].release_vote_gating = true), the generator computed release_vote_in_progress = (RC_VOTING_LABEL in issue_labels). The sync skill's pr merged → fix released transition removes the rc voting label and adds fix released; the two events combined made the generator compute release_vote_in_progress=False, which walks the embedded CNA_private.state back from REVIEW to DRAFT — the wrong direction for a record that's about to be published.

The merge-mode state-downgrade guard only refuses PUBLIC → non-PUBLIC, so a REVIEW → DRAFT push lands silently.

Real-world impact

Caught while syncing airflow-s/airflow-s#259 and airflow-s/airflow-s#377 after Airflow 3.2.2 shipped. The sync skill workaround was to pass --review on every regen, but that loses the auto-gate behaviour the config switch is supposed to provide and forces the operator to remember a flag.

Engelen's reviewer comment on CVE-2026-45192 ("This advisory doesn't seem properly populated at all, did you really intend to move it to 'REVIEW'?") was triggered by the under-populated record that landed before today's pre-push hygiene gates (#372) — but the state regression bug here is separate from the hygiene problem and would have continued biting after #372 merged.

Fix

Add a FORWARD_STATE_LABELS set (configurable via [workflow].forward_state_labels, default ["fix released", "announced - emails sent", "announced", "vendor-advisory ready"]) and OR it into the gate check in cve_json.py:

release_vote_in_progress = (
    RC_VOTING_LABEL in issue_labels
    or bool(FORWARD_STATE_LABELS & set(issue_labels))
)

Any forward-state label on the tracker means the release has shipped — the vote, if there was one, passed — so the rc-voting gate is moot and the state stays at REVIEW (or advances to PUBLIC on vendor-advisory).

Test plan

• test_forward_state_labels_keep_state_at_review_when_rc_voting_removed — verifies every default forward-state label keeps REVIEW.
• test_custom_forward_state_labels_from_config — verifies adopters can extend or replace the default set via [workflow].forward_state_labels.
• All 9 release-vote-gating CLI tests pass (pytest -k 'forward_state or rc_voting or gating').
• Pre-commit hooks green (ruff format re-applied + re-staged).

Follow-up

The sync skill can drop its --review workaround for the pr merged → fix released transition once this lands. The five pre-push hygiene gates from #372 remain unchanged — they target body-field quality, not the state gate.

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

• Yes — Claude Opus 4.7 (1M context)