docs(attest jira): improve CVE/multi-segment filtering help text

[jbrejner]

Summary

Improves kosli attest jira --help to surface the multi-segment identifier filtering behaviour that was previously only visible in internal godoc.

• Moved the filter description earlier so it reads as part of the matching rules (not as a branch-specific note)
• Broadened from CVE-only to any multi-segment match
• Replaced the ambiguous ^-<digit>^ placeholder with plain prose ("a hyphen and a digit")
• Added a warning for teams whose Jira project key itself matches the filter pattern (e.g. project key CVE), with a --jira-secondary-source workaround

Closes #949

Test plan

• kosli attest jira --help shows the new paragraph in the correct position
• Wording is clear and the CVE example is accurate
• make lint passes

[claude]

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

---

PR Review — docs(attest jira): improve CVE/multi-segment filtering help text

• Read changed file & gather context
• Static analysis (build / vet / mod tidy)
• Verify help text matches implementation in internal/jira/jira.go
• Post review feedback

---

Verdict: ✅ Looks good — ship it

This is a clean, docs-only change to the attestJiraLongDesc string constant. No behavioural risk.

Static analysis

Check	Result
go build ./...	✅ pass
go vet ./cmd/kosli/...	✅ pass
go mod tidy + git diff go.mod go.sum	✅ clean (no dep drift)

Accuracy vs. implementation

I cross-checked the new wording against FindJiraIssueKeys / isPartialMultiSegment in internal/jira/jira.go:121-175:

• "excluded if every occurrence … is immediately followed by a hyphen and a digit" — matches isPartialMultiSegment exactly: it returns true (filter out) only when all occurrences are followed by ^-\d (jira.go:161-174). ✅
• CVE-2026-41284 example — the candidate CVE-2026 matches the default pattern [A-Z][A-Z0-9]{1,9}-[0-9]+, and the trailing -4 triggers the dashDigit filter. The "followed by -4" explanation is correct. ✅
• The collision note (lines 49-52) now correctly scopes the risk to "an issue reference that happens to be the prefix of a longer hyphenated number" rather than the broader "all references filtered" claim. This resolves the concern from the prior review round (commit 4e96ad33). ✅

Notes

• The ^...^→backtick convention and em-dash usage are consistent with the surrounding help text. 👍
• No generated docs reference this command, so no regeneration step is needed.
• No tests required — help-text constants aren't golden-tested in this repo, and the underlying filtering logic already has coverage in internal/jira.

Nice work

The revised note strikes a good balance: it surfaces a real edge case (project key CVE) without over-warning teams who'd be unaffected in normal use, and points to a concrete --jira-secondary-source workaround. Moving the filter description up so it reads as part of the matching rules is a genuine readability improvement.
· docs/949-cve-filtering-help-text