feat(list repos): add --search, --sort-direction and --tag filters

[mbevc1]

Expose the query parameters added to GET /api/v2/repos:

• --search: filter repos by case-insensitive name substring (mutually exclusive with --name)
• --sort-direction: sort repos by name asc (default) or desc
• --tag: filter by tag key or key:value, repeatable

Mirrors the existing patterns in kosli list environments.

[claude]

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

---

Claude PR Review

Static analysis — all clean:

• ✅ go build ./...
• ✅ go vet ./cmd/kosli/
• ✅ go mod tidy (no changes to go.mod/go.sum)

Prior review feedback — both addressed ✅

• Sort ordering now proven end-to-end. Tests 14g/14h set up three deterministically-named repos (sort-a/-b/-c) and assert the returned order reverses under --sort-direction desc, so the flag is genuinely wired through — this resolves the earlier concern that the test would pass even if the flag were dropped.
• --tag uses StringArrayVar (listRepos.go:106), so each --tag is one literal entry and a tag value containing a comma won't be silently split. This follows the listControls.go convention and is the more correct choice for key:value inputs.

Code quality

• Cleanly mirrors the established listEnvironments/listControls patterns: option struct fields, conditional params.Set, params.Add loop for repeatable --tag, and MarkFlagsMutuallyExclusive("name", "search").
• Help text (long desc + examples) is thorough and accurately describes each new flag, including the --name/--search mutual exclusivity and the asc/desc default.
• Nice test coverage: substring search (14a/14b), mutual-exclusion error (14c), tag key and key:value (14d/14e), non-matching tag (14f), both sort directions, and the pure-unit TestPrintReposListAsTableRendersBlankTagsCell for table rendering.

Minor / optional (non-blocking)

• No client-side validation of --sort-direction. An invalid value (e.g. --sort-direction up) is passed straight to the server rather than rejected in validate(). This is consistent with listEnvironments (which also relies on the server), so it's a reasonable choice — just flagging that the error surfaces as a server response rather than a local usage error. No change needed unless you want to tighten it.

Summary

Solid, well-tested PR that faithfully mirrors existing conventions and has fully addressed both earlier review comments. No blocking issues. 👍