Reduce CI job count for pull requests

The current PR CI workflow (call-workflows.yml) triggers over 100 runner jobs on every pull request, covering the full integration and compatibility matrix including multiple compilers (gcc, MSVC, Clang, Intel, nvhpc, aocc), architectures (x86, arm64, i386, s390x), Java implementations (JNI/FFM), API versions (v1.6–v2.0), build modes, and Maven deployment tests.

While this breadth is appropriate for validating commits to develop, running the complete matrix on every PR creates unnecessary CI load and long feedback cycles for contributors.

Proposed changes, but I'm leaving it up to your engineering judgment:

Introduce a tiered CI strategy:

PR trigger — a fast smoke-test subset: Debug + Release on the three primary platforms (Ubuntu/gcc, Windows/MSVC, macOS/Clang), thread-safety, and concurrency builds.
Push to develop — the full matrix as it runs today.
Nightly / scheduled — slow or resource-heavy jobs: Intel, nvhpc, aocc compilers; Maven staging and binary deployment tests; full main-spc.yml API-version matrix; i386, s390x (bigendian already has this guard).

Benefits:

Faster PR feedback for contributors
Reduced GitHub Actions runner usage
Full coverage is still validated before anything merges to develop