fleet-ops: require claytonia's terraform gate

[cpitzi]

Closes #28.

claytonia/terraform/ applies on merge to main against the live Proxmox guests, but the repo's ruleset required only shellcheck / shellcheck and docs-check / docs-check — so a red plan, or a plan showing an unintended destroy, did not block the merge that would apply it. This adds gate, bringing it to parity with the other three enforced-surface repos.

Two of this issue's findings had gone stale in the eighteen days since it was filed, and the fix differs from what it proposed as a result.

kalmia already gates correctly. The issue recorded it as having no required_status_checks rule at all. It now requires gate, ansible-lint, shellcheck / shellcheck and docs-check / docs-check; drosera and solidago likewise require gate. claytonia was the only enforced surface still unguarded.

Requiring terraform / validate and terraform / plan as proposed would have deadlocked the repo. Those jobs sat behind an on:-level paths: filter, so on any PR touching no terraform they never ran — and a required check that never runs is held "Expected" forever, blocking every non-terraform PR. The issue predates that trap being understood. claytonia#69 instead ported the pattern the other three already use: the paths: filter moves off pull_request into a changes detector job, and an always-on gate fans in over changes/validate/plan under always(), failing on failure or cancelled while treating a skipped job as passing. One context, always reports, no deadlock.

The context is gate — bare, not terraform / gate — captured from claytonia#69's live check-runs, matching how the other three are mapped.

On the trade-off the issue asked to decide: requiring gate couples merge-ability for terraform PRs to LAN-runner availability, because plan runs on LXC 115. Accepted deliberately, and already the fleet norm — for a surface that applies on merge, a plan that cannot run is not a reason to merge anyway. Non-terraform PRs are unaffected, since plan skips and the gate passes.

On where to encode it: per-repo in this file, not taught to fleet-apply.sh. The base repo-ruleset.json stays check-agnostic by design, and this file is exactly the per-repo mapping mechanism — a terraform-aware special case in the script would duplicate it.

Verified end to end on claytonia#69 before mapping: changes, validate and plan all ran green with plan reaching the LAN runner, apply correctly skipped on the PR, gate green. The plan output was No changes. Your infrastructure matches the configuration., and the post-merge apply completed successfully — so the restructure did not disturb the terraform path.

Noted but out of scope: claytonia's queue-core check runs green on every PR and is not required. Requiring it is a separate decision from this issue.