feat(list flows): add --name and --ignore-case search flags

[mbevc1]

Wire the API's search_by_name and case_sensitive query parameters into kosli list flows via new --name and --ignore-case flags. The change is additive: when no --name is given the request URL is unchanged.

Closes #943

[claude]

Claude finished @mbevc1's task in 1m 44s —— View job

---

Review: PR #947 — --name / --ignore-case search flags for list flows

• Gather context (read changed files, diff)
• Static analysis (build, vet)
• Code review
• Post review feedback

---

Verdict: LGTM ✅ — clean, well-tested, additive change. The feedback from the previous review pass has been addressed.

Static analysis

Check	Result
go build ./...	✅ pass
go vet ./cmd/...	✅ pass

What's good

• Consistent with the codebase. The params := url.Values{} → base + "?" + params.Encode() pattern matches listSnapshots.go, listRepos.go, and listApprovals.go. The extra if encoded := params.Encode(); encoded != "" guard is actually a small improvement over those — it avoids emitting a bare trailing ? when no search term is given, keeping the no---name request URL byte-identical to before (matches the "additive, URL unchanged" promise in the PR description).
• Prior feedback resolved. The earlier note about o.name != "" being evaluated twice is fixed — the ignoreCase check is now nested under the name check, with a comment explaining why (case_sensitive only matters alongside a search term). The help text was also softened to "The Kosli API supports alphanumeric characters and '-'", so it no longer implies the CLI enforces a constraint it doesn't validate. Good resolution on both counts.
• Thorough tests. Five new cases cover the matrix that matters: substring match, no-match → empty list, case-sensitive-by-default, --ignore-case override, and short flags -n/-i. The SetupTest seeds a deterministic flow name with an explanatory comment. goldenJson "non-empty" assertions follow the existing convention (getAttestation_test.go, listEnvironments_test.go).

Minor (non-blocking) observations

• case_sensitive is only ever sent as "false" (when --ignore-case is set); the case-sensitive path relies on the server default. That's a reasonable choice and the comment documents it — just worth confirming the API default is indeed case-sensitive, which the "case sensitive by default" test exercises end-to-end. 👍
• The --name help mentions the alphanumeric/- rule but there's still no client-side validation. Given the softened wording this is fine as-is; if you ever want a friendlier early error for invalid input, a small validation slice + error-case test would lock it in — but it's optional and out of scope for this PR.

Nice, tidy PR. No changes requested.