waf: pass managedRules through set spec and outputs (SPEC-waf-managed-rules row 7)

[acoshift]

Implements the deploys CLI row of SPEC-waf-managed-rules (§14 row 7, CLI notes in §6): pass the new managedRules block through waf set/waf get/waf list.

What changed

• go.mod/go.sum: re-pin github.com/deploys-app/api to d2704814 (the api waf-managed-rules branch) so WAFSet/WAFItem carry managedRules with yaml/json tags and the CRS table column.
• internal/runner/waf.go: comment + -f usage now document the whole-replace contract — a spec that omits managedRules disables and clears it, so always start from waf get output. No runner logic change: the set path unmarshals straight into api.WAFSet, and table/yaml/json/toon outputs pick the field up from the api module.
• internal/runner/help.go + README.md: waf set help/docs mention managedRules and the omit-clears footgun.
• internal/runner/waf_test.go (new): pins the spec-file contract against api yaml-tag regressions — omitted managedRules decodes to nil (server clears), enabled:false keeps the curated excludedRules tuning, and waf get yaml (with read-only extras) round-trips into WAFSet intact.

Test evidence

• gofmt -l . clean; go build ./... and go vet ./... pass.
• go test ./...: 82 tests pass in 3 packages (repo has no PR CI; verified locally).
• Empirical round-trip with the pinned module + yaml.v2: disabled-but-tuned block survives get → edit → set; omitted managedRules marshals as JSON "managedRules":null on the wire (= server clears, matching whole-replace semantics); full-knob block round-trips.

Merge gate (why this is a draft)

The api pin v0.0.0-20260711014233-d27048143494 is the unmerged api waf-managed-rules branch (api PR not opened/merged yet; api main head is 7488037). api squash-merges, so this hash will never land on main. Per spec §14 sequencing, do not merge until the api contract PR merges, then re-pin go.mod to the post-merge api main pseudo-version (also picks up any api review fixes).

Rollout (spec §11)

This CLI change is inert until the platform side ships; sequence:

1. parapet release with the Coraza engine (Coraza managed-rules readiness: unconditional phase 2, zone match label, CRS include fixes, logged-matches-only metrics moonrhythm/parapet-ingress-controller#181) and CORAZA_ENABLED=true on target clusters — everything gates on this release.
2. api PR merges (then re-pin this PR).
3. deployer binary (SecLang materialization).
4. apiserver: apply the managed_rules column migration, then deploy the binary (migration-before-binary).
5. Flip features.waf.managedRules on the enabled locations (ops SQL, by name).
6. console/docs/mcp/CLI in any order after 5. Until the location flag flips, waf set with managedRules returns api.ErrLocationNotSupport — this CLI is safe to ship early once re-pinned.

Expected conflicts with sibling WAF branches

Three CLI WAF drafts re-pin go.mod to different unmerged api feature-branch pseudo-versions: this PR d27048143494, #59 (waf-events) 380d9eb5c22f, #58 (waf-ip-lists) 2a1d11a0be1d. go.mod/go.sum conflict pairwise; resolution: whichever merges after the first takes a fresh single pin to an api main pseudo-version containing all merged api PRs. internal/runner/waf.go merges cleanly with #59 (this PR edits the set case; #59 adds an events case after delete); no file overlap with #58 (new waflist.go + its help.go entry — help.go may need a trivial adjacent-line merge). There is no deploys-repo waf-test branch (api-side only).