pyjpegls: Add version 1.5.1

[luhenry]

• Package: pyjpegls
• Version: 1.5.1
• Source: https://github.com/pydicom/pyjpegls
• Docs: https://github.com/pydicom/pyjpegls

Compiles the vendored CharLS C++ library (via a git submodule) into a Cython extension exposing JPEG-LS encode/decode. Upstream publishes no riscv64 wheel.

Mirrors upstream's release-wheels.yml.

Differs from upstream

• Nothing beyond the riscv64 image.

Matrix: cp39/cp310/cp311/cp312/cp313, matching upstream's own wheel matrix; no cp314/cp314t (upstream ships neither, no Py_mod_gil slot).

Testing

• same as upstream

License: Wheel bundles CharLS (BSD-3-Clause); upstream ships no licence text for it, or even its own MIT one (case-sensitive glob miss on license.txt), so the patch adds both.

Patches

• 0001-package-the-CharLS-and-pyjpegls-licences-in-the-built-wheel.patch - To upstream, not yet submitted. Every pyjpegls wheel on PyPI has the same gap. Reproduces on x86_64 too.

Built on cp311 (x86_64 local check); 79 passed, 6 xfailed.

[luhenry]

CI triage for this PR:

What failed: in the Build pyjpegls wheels (riscv64) run (run 38377279040), cp39-manylinux_riscv64 built and tested cleanly (79 passed, 6 xfailed, license-file assertion passed, wheel uploaded), but cp310/cp311/cp312/cp313 all show conclusion: cancelled with runner_id: 0 (no runner ever assigned) and created_at/completed_at exactly 24h apart. check_commit_messages also failed on the first push because the PR description still carried a "Generated by Claude Code" footer; that was edited out and the check is green on the latest run.

Root cause: this is not a riscv64 or package-specific bug. The repo currently has 9+ Build * / PR verification checks workflow runs in flight at once across the open-PR backlog (pyarrow, greenify, headroom-ai, pyqir, quadrants, onnxruntime-openvino, iree-base-compiler, liftover, …) plus a large queued backlog, all competing for the same rise risc-v runners self-hosted pool. The four pyjpegls legs simply never got a runner within GitHub's 24h queued-job limit and were auto-cancelled — the one leg that did get a runner (cp39) passed outright, confirming build-pyjpegls.yml and the licensing patch are correct.

Fix applied: none needed to the workflow, patch, or docs/packages/pyjpegls.yaml — there's nothing to patch here. I triggered rerun-failed-jobs on the run (matching the existing playbook guidance for this exact shape: re-run, don't debug), which re-queued only the four missing legs; cp39's existing green result carries over. They're queued again as of now and should pick up a runner once the current backlog drains. If they get starved past 24h again, re-running is the right move each time — no code change will fix a capacity problem.