Add tests for jira-release-sync action

[jonathangreen]

Description

Adds an end-to-end test workflow for the jira-release-sync action that runs on every PR touching jira-release-sync/**.

The workflow:

• Starts a small Python mock_jira.py HTTP server that implements just enough of the Jira REST API surface used by action.yml (create version, list versions, link related work, update issue fixVersions) and records every request to a JSONL log.
• Runs the action against the mock server.
• Asserts via assert_calls.py that the recorded requests match a per-case expectations JSON file.

Two matrix cases are exercised:

• with_keys — release body contains PP-* references (including a duplicate and a different-project key that must be ignored), expecting fixVersions updates.
• no_keys — release body has no ticket references, expecting only the version + related-work calls.

Motivation and Context

The jira-release-sync action had no automated coverage, so regressions like the recent release-body handling fix (#4) could only be caught manually. This gives us a reproducible safety net for future changes to the action.

How Has This Been Tested?

• Mock server + assert script run locally against the action.
• The new workflow test-jira-release-sync.yml is the test plan — it will run on this PR.

Checklist

• I have updated the documentation accordingly.
• All new and existing tests passed.

[claude]

Claude finished @jonathangreen's task in 2m 57s —— View job

---

Review

• Gather context and read changed files
• Analyze mock server implementation
• Analyze test workflow and assertions
• Post inline comments for any bugs found
• Write summary

The test infrastructure is well-designed. The readiness-probe fix (bce1f1e) correctly handles the previously flagged issue — /__ready__ returns before _record is called, so it never appears in requests.jsonl. No new bugs found.

A few observations for the author's awareness:

• sort -u is lexicographic, not numeric. The action sorts extracted Jira keys with sort -u, so ABC-12 comes before ABC-7. The expected files are already written to match this ordering, so the tests are correct — but it's worth knowing the action will process PP-9 after PP-100 etc. for any future maintenance.
• assert_calls.py catches ordering regressions. Because project() preserves list order and the comparison is order-sensitive, any change to how the action iterates keys will be caught by the tests.
• _LAST_CREATED_NAME is global mutable state. This is fine since HTTPServer (not ThreadingHTTPServer) handles requests serially, but it means each test run implicitly depends on the POST happening before the GET. That matches the action's actual flow, so no issue in practice.