Summary

Consolidate the KWOK recipe-test workflow so all three tiers share one reusable workflow for the test steps and one source of truth for the deployer list. Today the deployer set and the Run KWOK test step block are duplicated across tiers, guarded only by a code comment.

This is a maintainability follow-up to the Tier 3 matrix-sharding fix (#1171) — that change deliberately scoped itself to the 256-config overflow and left this de-duplication for a focused PR.

Background

The Tier 3 sharding fix extracted the Tier 3 test steps into a reusable workflow (.github/workflows/kwok-tier3-shard.yaml) and moved the deployer list into the discover job's bash. That solved the overflow but left two kinds of duplication in place.

Duplication that remains

Deployer list — ["helm","argocd-oci","argocd-helm-oci","flux-oci"] appears in:

• .github/workflows/kwok-recipes.yaml — discover bash var (drives Tier 3)
• .github/workflows/kwok-recipes.yaml — the test-tier1 matrix axis
• .github/actions/kwok-test/action.yml — the input's doc string (prose only)

Tier 1 and Tier 3 must agree on the full four-deployer set; today that agreement is enforced only by a "keep this list in sync" comment. Tier 2 has no deployer axis (recipe-only matrix) — it exercises just the action's default deployer.

Run KWOK test step block — the checkout → load-versions → kwok-test trio with its ~13 version inputs is copied in three places: test-tier1, test-tier2, and the new kwok-tier3-shard.yaml.

Proposal

• Generalize kwok-tier3-shard.yaml into a single kwok-test-run.yaml reusable workflow that takes a pairs input (JSON array of {recipe, deployer}) and owns the only copy of the checkout/load-versions/kwok-test steps.
• Have discover emit the deployer list (or pre-built {recipe, deployer} pairs) as an output, defined once in bash. Tier 1 and Tier 3 both consume it. Tier 1 builds pairs the same way Tier 3 does, over the smaller generic-overlay set (well under 256 → no batching needed).
• All three tiers become thin matrix callers of kwok-test-run.yaml. The step block exists once; the deployer set exists once; action.yml's string stays as the only prose copy.

Net: editing the deployer set becomes a one-line change in discover, and Tier 1 ↔ Tier 3 drift becomes structurally impossible rather than comment-enforced.

Decisions to make in this work

1. Tier 2 deployer coverage. Consolidating forces a choice: does Tier 2 stay helm-only, or inherit the full deployer set? This is a coverage-policy call (more diff-aware deployer coverage vs. PR speed), not a mechanical side effect — decide it deliberately.
2. Check-name churn on the PR gate. Moving Tier 1/Tier 2 behind a reusable workflow renames their status checks (nested … / … names). ADR-003 §"Required checks" makes only KWOK Test Summary required precisely so matrix-name drift doesn't break branch protection, so this should be safe — but it touches the PR-gate path and warrants explicit verification.

Acceptance criteria

• The deployer list is defined in exactly one place; Tier 1 and Tier 3 consume it.
• The checkout/load-versions/kwok-test step block exists in exactly one reusable workflow consumed by all tiers.
• Tier 2 deployer coverage is an explicit, documented decision.
• KWOK Test Summary remains the required check; PR-gate behavior is unchanged (or the change is intentional and documented).
• ADR-003 updated if the tier/coverage structure changes.

Out of scope

The Tier 3 256-config sharding itself (handled in #1171) — this issue is purely the DRY/coverage refactor on top of it.