ci(release): gate every core bump — auto and manual — on config validation

[loss-and-quick]

Summary

Gates the weekly release's core auto-bump on the config-validation harness, so a new xray/sing-box version whose config schema drifted from our generators can't ship a broken build — and warns about the drift days earlier.

The release pipeline already auto-bumps the pinned core versions when upstream advances. Until now nothing checked that the new core still accepts the configs we generate; a schema change (a field a core starts rejecting, or a newly-required one) would sail straight into a release. This wires the validation harness in as a gate.

• scripts/check-core-compat.sh — stages the cores (honouring XRAY_VERSION/SINGBOX_VERSION overrides) and runs cargo test -p kasumi-core --test core_validation against them. A rejected config fails the script. Shared by both entry points below.
• release.yml (hard gate) — in prepare, when a core bump is detected (bins_changed), it stages the new versions and runs the check before the bump/tag. A rejected config fails the job → no bump, no tag, no release, until the generators are fixed. Exactly "no release-bump if the new version needs generator changes".
• core-compat.yml (early warning, no spam) — runs weekly (Sunday, a day before the Monday release cron) against the latest upstream cores. On drift it opens one tracking issue, deduped by a fixed title (a persistent drift never opens a second); when compatibility is restored it auto-closes that issue. So at most one open issue, ever.

Verified locally (against the staged real cores)

• Drift caught: with the pre-fix generators, the harness rejects 4 configs (naive + 3 shadowsocks ciphers) → check fails → gate would block. ✅
• Passes when matching: with the fix(singbox): make shadowsocks ciphers, naive uTLS, and naive libcronet work #104 generator fixes, 49/49 generated configs are accepted → gate lets the release proceed. ✅
• actionlint (both workflows) + shellcheck (the script) clean.

Affected layer

• frontend/ — React Web UI
• crates/ · src-tauri/ — Rust core / backend / Tauri desktop
• module/
• scripts/ — build / release helpers
• CI / .github/
• Docs only

Verification

• actionlint .github/workflows/core-compat.yml .github/workflows/release.yml
• shellcheck scripts/check-core-compat.sh
• Harness drift signal verified both ways (4 rejected pre-fix → blocks; 49/49 with fixes → passes)
• PR CI green (the workspace core_validation test skips without staged cores, as before)

Checklist

• Title is a scoped Conventional Commit
• No build artifacts committed (cores stay gitignored; staged at check time)
• No user-visible strings / project-id renames

Notes for reviewers

• Stacked on test(rust): widen unit coverage across core, backend, desktop #103 (the validation harness it calls lives there) and depends on fix(singbox): make shadowsocks ciphers, naive uTLS, and naive libcronet work #104 (the generator fixes): the gate/early-warning only pass once the pinned cores match the generators, which is true after fix(singbox): make shadowsocks ciphers, naive uTLS, and naive libcronet work #104. Merge order: fix(singbox): make shadowsocks ciphers, naive uTLS, and naive libcronet work #104 → test(rust): widen unit coverage across core, backend, desktop #103 → this. The diff here is just the three CI/script files.
• The early-warning issue dedup uses a fixed title search (in:title "Core compatibility: …") rather than a label, so no label needs provisioning.
• The release gate adds a Rust toolchain + the harness to prepare only when bins_changed — it's a no-op on ordinary releases.

Update: also covers manual bumps (not just the auto-bump)

The release gate only runs in release.yml, i.e. for the auto-bump. A collaborator hand-editing core-versions.sh (or the generators) in a normal PR would have bypassed it. core-compat.yml now also triggers on pull_request touching scripts/core-versions.sh, scripts/fetch-cores-desktop.sh, or crates/kasumi-core/**, validating the versions the PR pins against the real cores. So no path — automated or manual — can land a core our generators don't match.

Note on access: triggering a release (workflow_dispatch) needs repo write access, and pushing to main is blocked by the branch ruleset (release.yml uses a dedicated RELEASE_TOKEN PAT precisely to bypass it), so an outsider can't cut a release or push a bump to begin with — this closes the remaining gap for collaborators who can.