Add CI guardrail to detect stale BoringSSL fork

[kaukabrizvi]

Problem:

s2n-tls now depends on a fork of BoringSSL after #5659. This fork dependency is required to enable symbol prefixing and avoid OpenSSL symbol collisions to run integration tests with BoringSSL until symbol prefixing can be enabled upstream. This dependency introduces a maintenance risk if the fork silently goes stale.

Solution:

Add a lightweight CI “time-bomb” check that fails if the BoringSSL fork has not been updated within a defined window (e.g., 6 months). The failure should clearly explain how to refresh or re-sync the fork.

Requirements / Acceptance Criteria:

• CI fails when the fork exceeds the staleness threshold
• Failure message is clear and actionable
• Check is easy to maintain and adjust