waf: add events subcommand (SPEC-waf-events row 6)

[acoshift]

Summary

CLI leg (rollout row 6) of SPEC-waf-events (Firewall Events — sampled WAF match/block samples, waf.events).

• New deploys waf events subcommand: flags map 1:1 onto api.WAFEvents — -project, -location, -rule (short id from waf get), -action (log|allow|block), -before (keyset cursor), -limit (default 50, max 200). Rendered via WAFEventsResult.Table() through the standard rn.print path; -ojson/-oyaml/-otoon work as usual.
• Table mode prints a next: <cursor> trailer when more pages exist (the table has no cursor column, so without it a table-mode user could not obtain the -before value; structured modes already carry next in the payload).
• Help entry under waf, marked as sampled events.
• api re-pinned for the WAF.Events types.

Example (illustrative values only):

$ deploys waf events -project my-project -location gke.cluster-rcf2 -action block
TIME   ACTION   RULE   IP   COUNTRY   METHOD   HOST   PATH
...
next: 01ARZ3NDEKTSV4RRFFQ69G5FAV
$ deploys waf events ... -before 01ARZ3NDEKTSV4RRFFQ69G5FAV

Merge gate — DO NOT MERGE until api PR lands

go.mod currently pins github.com/deploys-app/api v0.0.0-20260711011307-380d9eb5c22f, the tip of the unmerged api waf-events branch (api main has no waf.events yet, and api squash-merges, so the merged commit will differ). Per SPEC-waf-events §J the api PR (row 2) merges first; re-pin this branch to the merged api main commit (usual "re-pin api" pattern) before merging.

Expected merge conflicts

The open waf-ip-lists branch touches the same files:

• go.mod / go.sum — both branches re-pin deploys-app/api to different branch-tip pseudo-versions (definite conflict; whichever branch merges second re-pins to the api commit containing both features).
• internal/runner/help.go — this branch adds the events sub inside the waf block; waf-ip-lists adds a wafList block immediately after it (adjacent hunks, likely textual conflict; trivially resolvable).

Test evidence

Repo has no PR CI; verified locally:

• gofmt -l . clean; go build ./... && go vet ./... clean
• go test ./... — 78 tests pass in 3 packages
• Built binary exercised: waf --help lists events; waf events -h shows all flags with the correct usage line

No test added for the subcommand itself: the flag→request mapping is declarative and compile-checked against the api types, and no existing waf subcommand has one (runner tests cover pure helpers only) — matches the established pattern for thin subcommands.

Rollout notes (SPEC-waf-events §J)

Safe order — every step independently inert:

1. apiserver: apply the waf_events migration before the binary
2. apiserver binary (collector.setWAFEvents + waf.events mounted; table empty until fed)
3. parapet-ingress-controller image + WAF_EVENTS_TOKEN Secret + headless Service (endpoint off until both envs set; inert until polled) — engine side already implemented in feat(waf): sampled match-event ring + direct push to the deploys-app collector moonrhythm/parapet-ingress-controller#182
4. collector: set waf_events_target + waf_events_token envs (unset = loop never runs, so the binary can ship early)
5. console events table, then docs

This CLI change ships on the next CLI build after merge, independent of the deploy steps above (rows 2–3 must be merged for the api pin, per the gate; against an older server waf.events simply returns unknown action). No secrets involved; examples use placeholder values only.