ci: fix Ubuntu Noble compatibility & optimize CI pipeline

[Arthurvroum]

Context

CI jobs on ubuntu-latest were experiencing extreme slowdowns (tens of minutes or outright timeouts). Investigation traced the root cause to three independent bottlenecks.

---

Changes

1. Fix LLVM/APT repository for Ubuntu Noble — ci.yml

Problem: The workflow hardcoded the jammy APT repository for LLVM, while ubuntu-latest now runs Ubuntu 24.04 (Noble). This forced apt to compute endless downgrade paths and resolve libc conflicts, taking several minutes.

Solution: Replaced the hardcoded jammy string with $(lsb_release -cs). The target repository now adapts dynamically to the runner's actual OS version.

---

2. Repair and optimize test caching — run_test.py, ci.yml

Problem (run_test cache): The cache invalidation key relied on st_mtime_ns (file modification timestamp). Every CI build recompiled the binary, generating a new timestamp and silently invalidating the entire cache on every run. No actions/cache step persisted it between runs.

Problem (IR cache): Clang re-parsed all source files and standard headers (<vector>, <iostream>, …) from scratch for each of the 1,661 tests.

Solution:

• Cache keys now use a SHA-256 hash of the analyzer binary, making them independent of build timestamps.
• Added actions/cache@v4 steps for both the run_test directory and the new Clang IR cache (--compile-ir-cache-dir=.cache/compile-ir via EXTRA_ANALYZER_ARGS). The expensive Clang parsing cost is now paid only once.

---

3. Parallelize run_code_analysis.py (Self-analysis)

Problem: The Self-analysis step (~4 min 55 s observed) ran on a single thread via a sequential subprocess.run() loop, leaving all other CPU cores idle.

Solution: Implemented multi-threading via concurrent.futures.ThreadPoolExecutor. The workload is split into balanced chunks based on os.cpu_count(). JSON diagnostics and SARIF reports are processed in parallel and merged at the end.

---

[Arthurvroum]

Fix redundant CI job cancellations — ci.yml

Problem: GitHub Actions triggered two duplicate pipeline runs on every push (one for push, one for pull_request). The concurrency rule immediately cancelled one of them, resulting in false-positive "Cancelled" statuses and red cross icons in the UI.

Solution: Removed the explicit branch reference from the push trigger in .github/workflows/ci.yml. The CI now purely relies on the pull_request event, showing clean and deterministic success/failure statuses.