Fix: st41 fastmetadata pytest failures and stale SvtJpegxs CI staleness check

[awilczyns]

Fixes test_st41_no_chain (ST2110-41 fast-metadata, no-RTP-chain mode) end
to end: a missing JSON fps option that made the RxTxApp config rejected, a
tx-side packet-size validation bug that rejected every packet, and a CI
staleness check that let a stale SvtJpegxs install silently break the
FFmpeg plugin build.

Changes:

Fix: parse_json.c — st_json_parse_tx_fmd()
only recognized p25/p29 for the fast-metadata fps JSON field; the
higher/lower frame rates used by test_st41_no_chain (p119, p120,
p100, p60, p30, p24, p23) fell through to the invalid fmd fps
error path. Added the missing mappings to ST_FPS_*.

Fix: st_tx_fastmetadata_session.c —
tx_fastmetadata_session_build_packet() validated packet capacity against
rte_pktmbuf_data_len(pkt), which is 0 right after rte_pktmbuf_alloc()
and still excludes the RTP header at the second check point. Both checks
therefore rejected every packet unconditionally (packet is less than fmd hdr size / invalid pkt_len 0 for every packet, per the failing-run log).
Switched to rte_pktmbuf_tailroom(pkt) [+ rte_pktmbuf_data_len(pkt)], which
reflects actual buffer capacity instead of bytes committed so far.

Fix: setup_environment.sh — the JPEG-XS
need_build staleness check only tested ldconfig SONAME presence, not
version, so a stale SvtJpegxs core lib (surviving git clean as a
system-wide install on a persistent self-hosted runner) was treated as
up-to-date after versions.env required SvtJpegxs >= 0.10.0 for the
FFmpeg plugin build. Added a pkg-config --atleast-version check so an
outdated install now triggers a rebuild instead of being silently skipped.
The minimum version is a new versions.env variable
(SVT_JPEG_XS_MIN_VER), matching the existing convention for pinned
versions rather than a literal in the script.

[DawidWesierski4]

weak review from me

i read this it makes sense
if i had time i would look into wiht GDB into it but i don't