spectrack: Jira Data Center read inverts blocking/blocked_by issue-link direction

[studykit]

Summary

On the Jira Data Center issue provider, the read path inverts blocking ↔ blocked_by for issue-link relationships. A relationship written via spectrack issue link reads back as its opposite, so cached relation.md / workflow projections misreport hard dependency direction.

GitHub dependencies and the Jira write path are correct; only the Jira read normalization is affected. related (symmetric Relates) happened to survive, and parent/child come from fields.parent/fields.subtasks, so those are unaffected.

Root cause

The word direction meant two different things:

• create_issue_link (write) keys direction on the source issue's side of the link.
• _issue_link_target_and_label (read) keyed direction on the far issue's side — i.e. whichever of inwardIssue/outwardIssue Jira populated.

Jira always populates the opposite end when you GET an issue, so the read direction was systematically the inverse of the write direction. Round trip: write blocked_by → read blocking.

The existing read fixtures were hand-authored to match the buggy reader rather than real Jira GET output, so tests passed while masking the inversion.

Fix

• plugins/spectrack/scripts/issue/jira/relationships.py — _issue_link_target_and_label now reports the source issue's side (invert the populated field), matching the write/config definition.
• Corrected the Jira read fixtures in test_jira_issue_provider.py and test_cache_fetch.py to real Jira GET shape; updated the unmapped-link display assertion in test_jira_issue_cache.py.
• Added a parametrized write → simulated GET → read round-trip regression test that drives the real create_issue_link and normalize_jira_data_center_issue, so neither side can silently re-invert. Confirmed it fails on the pre-fix code.

References the same Jira link-direction lineage as #131.