Use constexpr effectively

Before I submit this change to the library, make it easy for reviewers to see which computations became compile-time: move pure helpers into a header with constexpr, put the key results at the top as static constexpr variables, show one example of a static_assert testing expected behavior, and mark code that cannot be constexpr with a brief comment explaining why to avoid guessing during review.

I modified core::compute to be constexpr and added static_asserts, but at runtime some unit tests that exercise dynamic inputs now fail in subtle ways. Team members are Tim who wrote compute and Aisha on test infra. I’m worried I changed evaluation order or removed a runtime guard. Is this likely that making it constexpr exposed a UB or tightened evaluation rules, and what quick checks should I perform to confirm the compile-time changes are safe for dynamic inputs?

Over several releases we keep retrofitting constexpr on utilities and occasionally introduce regressions in dynamic paths or tie ourselves to a specific standard version. The pattern is lack of a policy for when something should be constexpr and inconsistent test coverage. Which simple rules and review practices should we adopt so constexpr is used where it helps and never breaks runtime behavior or portability?