ci: parallelize the golden gate and free the package job

[Jo5ta]

What

Cuts CI wall-clock time by attacking the two things a timing analysis showed dominate it: the golden format gate (~740s) and the serial package tail (~100s).

Why (measured, from a passing run)

Golden was the critical path: two ~6-min qemu-emulated legs (le-aarch64, be-s390x) ran back-to-back in one job — aarch64 367s + s390x 359s = ~726s of pure emulated-build compute — and it ran on every code||tests||ci PR. package then ran serially after build-and-test even though it builds its own rpms.

Changes

• Split golden by byte order into golden-le + golden-be so the two legs run in parallel (step_golden.sh was already parameterized by CLLTK_GOLDEN_ARCHES). Wall-clock for golden goes from le + be to max(le, be).
• golden-le runs on a native ARM64 runner (ubuntu-24.04-arm) — no qemu. Only the s390x leg needs emulation (no native s390x runners exist).
• Path-gate golden on a new golden filter (tracing_library/, the golden generator, the cmake preset, the gate script). The trace format can only change through those, so the slow job is skipped on the majority of PRs.
• Free package: depend on checks instead of build-and-test. It builds its own rpms (cmake --workflow --preset rpms), so the build-and-test dependency was only a gate; it now runs in parallel. Trade-off: it builds on PRs whose tests fail (cheap; the PR fails anyway).

Expected impact

• Non-trace PRs: golden skipped entirely → the two ~6-min legs disappear from the run.
• Trace PRs: golden ≈ the s390x leg alone (~6 min emulated) instead of ~12 min; the LE leg is native and fast.
• package's ~100s comes off the critical path.

After this, build-and-test (dominated by the ~270s Python suite) becomes the pole — a follow-up will split that into parallel jobs.

⚠️ Branch protection

This renames the golden status check to golden-le / golden-be. If golden is in the required-status-checks list, that list needs updating (replace golden with golden-le and golden-be), or the required check will never report and block merges.

Testing

• step_golden.sh with CLLTK_GOLDEN_ARCHES=aarch64 (the LE leg) and =s390x (the BE leg) are validated locally; the workflow YAML parses and the job graph is correct. Full behavior confirmed by this PR's own CI run.