feat: read Jira summary and status for every key in batched searches

[lesnik512]

First step of the Jira phase: summary and status for every Jira key in the report.

What changes

• RELEASE_SCOPE_JIRA_TOKEN (or JIRA_TOKEN) enables Jira. With RELEASE_SCOPE_JIRA_ENDPOINT, collect reads all keys of the report through POST /rest/api/2/search, 100 keys per query, Bearer auth (Jira Server/Data Center).
• The report gets a top-level jira block: issues by key (summary, status, status category, issue type), missing keys, and error. It is null without a token.
• A failed search is kept in the report; the GitLab part is still written and collect exits 1. A token without an endpoint exits 2.
• Page: each key shows as [KEY](url) summary · status; the summary table gains a Jira column counting not-done issues per service; a Jira error shows under the legend.
• schema_version is now 2. render rejects version 1 with "run collect again".

Design notes

• POST instead of GET keeps 100 quoted keys out of the URL. Retry covers POST for Jira only: the search is read-only.
• validateQuery: false lets Jira skip unknown keys (for example UTF-8 without a project allowlist) instead of failing the batch. Verified on a real Data Center instance.
• "Not done" uses the status category, not the status name, which differs per workflow.
• Jira data is not cached: no status is settled, and batching keeps it at one or two requests per run.
• An issue moved to another project returns under its new key, so the old key lands in missing.

Next

Remote links (related services per key), then the --jira KEY mode with per-project cache pruning.