Record the state of linked merge requests and show it on the page (schema 7)

[lesnik512]

Closes #30. Report schema 7; release as 0.9.0.

Each merge request link of a Jira issue that points into a collected service now has state (opened, closed, locked, merged) and target_branch. When a row holds the merge request, it is recorded as merged into the default branch without a request. Otherwise the collector reads it, at most once per run, through the same _linked_merge_request that --jira uses, so a merged one is cached as a settled fact. In a --jira run, _link_target records the state of the merge requests it already reads, and the later pass reuses them, so none is read twice.

The state stays null for commit links, for projects outside the report, for services that failed or have CI/CD or Environments disabled (the README says those are not queried), and when GitLab cannot return the merge request. A failed read does not fail the service or the run; the page then falls back to the old wording.

Closed merge requests still count as touching the service, and there is no flag: a merged one is cached, so a large group pays mainly for open ones.

On the page, an issue that links only to changes outside the range now says why: not merged (open or locked), in prod (merged into the default branch), older than the range (the same, when the range was cut at RELEASE_SCOPE_MAX_COMMITS), merged into <branch>, or closed. in prod or not merged remains for commit links and unreadable merge requests. The service line lists these states even when a tag is picked for other chosen issues, so a picked tag no longer hides that a chosen issue is not merged in that service. New strings exist in English and Russian.

Every earlier schema bump shipped as a new minor version with the skill's range moved, so the README's Pages example, its skill note, and SKILL.md now run release-scope>=0.9,<0.10. The README's Report section and SKILL.md describe the new fields.

Tests, written first and failing before the change: a link held by a row is merged into main with no request; a link outside the range records opened, closed, merged into another branch, and merged into main; a merged one comes from the cache on the second run; a 404 leaves the state unknown and the service intact; a --jira run records the states of its scope links and reads each merge request once. just test-ci (140 passed, 100% coverage) and just lint-ci pass. The page has no tests; I checked it in a browser against a mock schema-7 report with each state, in English and Russian, with no console errors.