ci(jira): automate the ticket lifecycle and publish GitHub releases

[yasin-ce]

Description

Automates the PERA ticket lifecycle and publishes GitHub Releases, both driven from GitHub Actions.

Bitrise builds; GitHub automates. No Jira credential is copied into Bitrise. "A release shipped" is read from the check run Bitrise's GitHub integration already posts, so the Jira rules live in one place and a Bitrise config change can't silently stop moving tickets.

When	Target status	Also
Ticket branch first pushed	In Progress	—
PR opened non-draft, or marked ready	In Code Review	—
PR merged to main	In Code Review	assigned to QA
Nightly (-alpha.N) shipped green	Ready for QA	—
RC (-rc.N) shipped green	Ready for QA	fix version stamped
Store (vX.Y.Z) shipped green	Done	only from Waiting for Deployment

Also publishes a GitHub Release per release tag (the repo has 50+ tags and no releases; workflow_dispatch doubles as a backfill), and adds a CI Lint job running actionlint, shellcheck and the new shell test suites.

Full write-up: docs/CI_AUTOMATION.md.

Related Issues

• No ticket — CI/tooling.

Checklist

• Have you tested your changes locally?
• Have you reviewed the code for any potential issues?
• Have you documented any necessary changes in the project's documentation?
• Have you added any necessary tests for your changes?
• Have you updated any relevant dependencies?

Additional Notes

This writes to a live tracker, so the safety rules are the substance of the review, not the plumbing:

• Forward-only — a ticket only moves up the pipeline, so a later commit citing an already-tested key can't reopen it. Off-pipeline states (Blocked, *Input Needed, Cancelled, Duplicate) are treated as deliberate parking and left alone.
• Board-scoped, failing closed — keys come from free text (branch names, PR titles, commit subjects), so every candidate is confirmed against the React Native board filter first; a PR citing a Backend ticket can't move it. If the scope check itself fails, nothing is written.
• A commit is mandatory — tickets that ship no code (QA tasks, investigations) are never touched by a build; a person moves those. There is deliberately no status-based sweep.
• Never fails a build — every stage exits 0; problems surface as warning annotations. jira-drift.yml exists precisely because that choice is otherwise silent: a rotated token would just stop moving tickets, so a weekly read-only report fails loudly when git and Jira disagree.
• Reads retry, writes don't — a mutating request that timed out may already have applied server-side, so re-POSTing a transition would report a spurious failure.
• DRY_RUN=1 makes any stage read and report while withholding every write. Worth using for the first run.

pull_request_target in jira-sync.yml is deliberate and worth a reviewer's eye: this repo is public, and a pull_request run from a fork gets no secrets, so the sync would silently never happen. It is safe here because no PR code is checked out or executed — the checkout is the base ref, and the PR title/branch reach the script through env, never interpolated into a shell command. Fork PRs are additionally excluded by the job if, so nobody can move an arbitrary ticket by naming it in a PR title.

Known rough edges, left as-is:

• api() merges stderr into the response body, so a connection failure makes the warning read HTTP curl: (6) Could not resolve host…. It still fails correctly, just prints oddly.
• jira-release-sync.yml uses mapfile (bash 4+) while tools/lib/jira-api.sh documents bash 3.2 compatibility. Fine on runners; only bites if run on stock macOS bash.
• check_run: completed queues the release-sync workflow for every check run in the repo. The job-level if means no runner starts, so it's cheap, but the event volume is high.
• CI Lint runs shellcheck --severity=error only. The pre-existing warnings are real, but two are in tools/generate-config.sh on the production config path and deserve their own change with a test.

Verification: 5 shell suites / 57 assertions pass against a stubbed Jira (tools/__tests__/). All workflow YAML parses. The workflows themselves can't be exercised locally — this PR's own CI Lint run is the first real check, and the Jira stages only fire on their triggers.