Resurrect 6 disabled GitHub workflows (kani-verification, kani-regression, capability_tests, status-dashboard, deploy-verification, docs-deploy)

[avrabe]

Part of the V&V coverage initiative.

Problem

kiln has the largest Kani portfolio in pulseengine (ASIL-profile harnesses in kiln-sync/tests/kani_proofs.rs, Kani-verify integrated into cargo-kiln), but six GitHub workflows are currently on disk as .yml.disabled:

• .github/workflows/kani-verification.yml.disabled
• .github/workflows/kani-regression.yml.disabled
• .github/workflows/capability_tests.yml.disabled
• .github/workflows/status-dashboard.yml.disabled
• .github/workflows/deploy-verification.yml.disabled
• .github/workflows/docs-deploy.yml.disabled

Verification runs locally via cargo-kiln kani-verify --asil-profile <level> but nothing enforces it on PR merge. For DO-178C / ISO 26262 tool-qualification evidence, the gate must run on every push.

Acceptance

• Each disabled workflow is audited, updated for the current cargo-kiln CLI, and renamed to .yml
• Kani verification runs on PR with ASIL-D profile; ASIL-C/B as matrix if feasible
• kani-regression runs nightly on main, posts results as a badge
• capability_tests gates the memory-capability system (safe_managed_alloc! invariants)
• status-dashboard generates a published artifact (pages or similar)
• deploy-verification and docs-deploy are either re-enabled or deleted with rationale in the PR
• Update kiln/.github/kani-badge.json to reflect live CI status
• CI green on main; document the workflow topology in docs/

Notes

• Kani tool version is pinned in kiln/tool-versions.toml; use that
• Harnesses are in kiln-sync/tests/kani_proofs.rs and across kiln-foundation/src/formal_verification.rs
• This is the single highest-leverage CI move for the whole estate per the initiative tracking issue

[avrabe]

Started this with #281, which re-enables the KANI workflow (kiln's 22 harnesses — the biggest gap from the verification audit, #280) scoped to weekly + manual so it runs without blocking PRs. Promote to PR-gating once green.

Remaining disabled workflows can follow the same staged pattern: kani-regression (same nightly approach), capability_tests (assess + re-enable if green), deploy-verification / status-dashboard (lower-risk, likely re-enablable directly). Keeping this issue open to track those.

[avrabe]

Triage sweep — accurate current state (2026-06-13). Audited .github/workflows/:

• ✅ kani-verification.yml — active (weekly + manual, ASIL a/b/c/d), re-enabled via ci(kani): re-enable KANI formal verification as weekly + manual (#237) #281.
• ⏳ still .yml.disabled: kani-regression, capability_tests, status-dashboard, deploy-verification.
• ⚠️ docs-deploy — does not exist as .yml or .yml.disabled; only deploy-docs-sftp.yml.example is present. So the title's "6 workflows" is really 1 done + 4 disabled + 1 that was never committed. Suggest dropping docs-deploy from the checklist (or recreating from the .example if docs-deploy is actually wanted).

Remaining actionable: the 4 disabled workflows, each via the staged pattern #281 used (weekly/manual → promote to PR-gating once green). Kept open.