v2.2.6 — Transfer-syntax negotiation list + backend/lossless reporting fixes

Shared transfer-syntax negotiation token list for dicom-retrieve/dicom-qr, plus two reporting-accuracy fixes (--backend, dicom-compress info lossless state). No association-negotiation or encode-behavior changes — this release only corrects what tools report and what token lists they offer.

Added

• TransferSyntax.negotiableImageSyntaxTokens / negotiableImageTokens (DICOMCore) is now the single source of truth for the transfer-syntax lists offered by dicom-retrieve/dicom-qr — the negotiation analogue of CompressionManager.supportedCodecs() (dicom-compress) and DICOMConverter.cliTokens (dicom-convert). Every token round-trips through TransferSyntax.parse().
• The DICOMStudio CLI Workshop dicom-retrieve/dicom-qr pickers and the CLI --transfer-syntax help now derive from that shared list, adding the previously-missing JPEG-LS, JPEG XL, and JPEG 2000 Part 2 (plus explicit-vr-be, deflate, jpeg-extended, jpeg-lossless-sv1) syntaxes the old hand-maintained lists stopped short of.
• CLI Workshop: the dicom-convert transfer-syntax dropdown now shows the short kebab aliases (e.g. jpeg2000-lossless, htj2k-lossy) instead of CamelCase, matching the other tool pickers. The CLI resolves the alias identically, so generated commands are unchanged.

Fixed

• dicom-compress info: for the both-capable general J2K/HTJ2K/JXL UIDs (.91/.93/.203/.112), isLossless and the transfer-syntax display name are now derived from Lossy Image Compression (0028,2110) instead of the UID-level flag, which always reported "Lossy". A file reversibly encoded into a general UID now reports Transfer Syntax: JPEG 2000 Lossless / Lossless: Yes consistently instead of contradicting itself.
• --backend reporting now reflects the backend an encode actually dispatches to, not the best available hardware. Metal (GPU) is only used for genuinely lossy JPEG 2000/HTJ2K encodes (the lossless GPU path isn't bit-exact on 12/16-bit medical data), so auto/--backend metal previously reported "Metal (GPU)" for lossless/non-J2K encodes that actually ran on the CPU. An explicit --backend metal request that can't use the GPU is now downgraded with an explanatory note.
• CodecBackend.accelerate.displayName reports "Accelerate (CPU)" instead of the stale "Accelerate (not available)" now that the old J2KAccelerate SIMD probe has been removed upstream (J2KSwift v11.0.0) while Accelerate itself remains available.