fix(attest jira): accept --jira-project-key lists written with spaces

[mbevc1]

--jira-project-key is a StringSliceVar, and pflag splits those with encoding/csv, which never trims. So a list written the way most people type one arrived with the whitespace attached:

`--jira-project-key "ABC, DEF"  ->  {"ABC", " DEF"}`

validateJiraProjectKeys then rejected " DEF", because a leading space fails ^[A-Za-z][A-Za-z0-9_]{1,9}$, and the command exited non-zero on input a user reasonably expects to work. Verified against a binary built before this change:

`--jira-project-key "ABC, DEF"  Error: invalid Jira project keys: [ DEF]`
`--jira-project-key " ABC"      Error: invalid Jira project keys: [ ABC]`

Trim the keys in place before validating, so one canonical key reaches both the validator and jira.FindJiraIssueKeys instead of each trimming separately and having to agree. internal/jira already trims the keys it interpolates; that now becomes belt-and-braces rather than the only thing standing between a padded key and a pattern matching " ABC-123".

Two neighbouring behaviours are deliberately left alone. A trailing comma, as in --jira-project-key "ABC,", is already refused while pflag is still parsing, by the empty-element rule in nonEmptyValue.go, with clearer wording than this validator could give it. A whitespace-only element slips past that rule, since it is not empty, so "ABC, " still fails here - now displayed as an empty key rather than a space. Teaching the repo-wide empty-value rule to treat whitespace as empty would change all 165 flags and wants its own audit.

Closes #1115

Checklist

• Docs are autogenerated from CLI help — make sure the help text reflects your changes
• Helm chart (charts/k8s-reporter/) updated, if needed. Note: these changes live in a separate PR
• Terraform provider and related changes (terraform-provider-kosli, terraform-aws-evidence-reporter, terraform-aws-kosli-reporter) updated, if needed

[claude]

Claude finished @mbevc1's task in 3m 20s —— View job

---

Review — round 5 (71a392c6)

• Read PR diff and changed files
• Static analysis (go build, go vet, go mod tidy)
• Review code quality, edge cases, tests
• Post review

Static analysis

Check	Result
go build ./...	pass
go vet ./...	pass
go mod tidy + git diff --exit-code go.mod go.sum	clean

I could not run go test in this environment (command not permitted here, and the suite needs the local Kosli server plus KOSLI_JIRA_API_TOKEN/KOSLI_JIRA_USERNAME), so the assessment below is by inspection. If you want the test run included in future passes, go test ./cmd/kosli/... needs to be in --allowedTools.

Previous rounds

All three earlier threads are resolved in the current head:

• Ordering hazard — the trim now happens as the first statement of validateJiraProjectKeys (attestJira.go:408), so a future caller can't reach the regex with untrimmed keys. This was the substantive one.
• %v hiding an empty key — %q at attestJira.go:417 makes [""] visible, with golden and unit tests updated to match.
• Validation-only tests — 20b/20c now carry --assert, so they run the whole path rather than stopping at validation.

This round

Nothing blocking. Two notes:

1. attestJira_test.go:279-281 — the 20c comment still describes a state internal/jira can't produce. Inline suggestion posted; purely cosmetic.
2. Adjacent, out of scope — --jira-issue-fields on this same command is a plain StringVar documented as "comma separated list" and passed verbatim into the Jira fields query param (attestJira.go:261 → internal/jira/jira.go:93). --jira-issue-fields "summary, description" has the same "written the way people type it" shape this PR fixes for project keys, one layer further out. Worth a follow-up check rather than anything here — and it's a raw string, so it isn't covered by the 165-flag nonEmptyValue audit the PR body defers.

What's good

• Trimming in place means one canonical key reaches both the validator and FindJiraIssueKeys, which is the right fix — the alternative (each side trimming separately) is exactly the kind of agreement that rots.
• The doc comments state why rather than what, including why %q over %v, so the empty-key rendering can't be silently reverted by someone tidying up verbs.
• TestValidateJiraProjectKeys's "a padded key is accepted and left trimmed" asserts on o.projectKeys directly, which is what actually pins the canonicalisation property — the suite tests are end-to-end colour on top of it.
• Deliberately leaving the trailing-comma and whitespace-only-element cases to the existing nonEmptyValue rule, and saying so in the PR body, keeps the blast radius at one flag.
• Help text (root.go:168) updated to match the newly-supported input; client_reference is generated at release time so there's nothing checked in to regenerate.
  · branch 20260820_jira_normalise