fix(lint): constexpr-constant asks clang's evaluator, not the initialiser tokens

The first cut scanned the initialiser's tokens and required every one to be a
literal or an operator. That is exactly the kind of approximation this work has
been removing, and it was wrong in both directions:

  const int A = sizeof(Big);   missed — `sizeof` is a keyword
  const int B = Base + 1;      missed — `Base` is an identifier
  const auto C = 5_notConstexpr;  would have been reported, wrongly

clang_Cursor_Evaluate answers the question directly. Evaluating a variable
declaration evaluates its initialiser, so anything that folds is recognised and
a call result still is not. Costs nothing measurable — lint stays at ~15s.

Found one real case the token version could not see: an EShMessages fold over
three glslang enum constants in Crafter.Build-Shader.cpp. Promoting it to
constexpr then made `naming` ask for constant naming, since a constexpr
variable is a compile-time constant — so it is `Messages` now. Two rules
agreeing on the same declaration is the intended behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

interfaces/Crafter.Build-Clang.cppm

@@ -215,6 +215,10 @@ export namespace Crafter {
         // for a declaration whose uses are all in this file, so a local rather
         // than something with external linkage.
         bool isMutated = false;
+        // The initialiser is a constant expression, as decided by clang's own
+        // constant evaluator rather than by inspecting its tokens. Only set for
+        // Variable and Field.
+        bool isConstantInitialised = false;
         // Method declared const. Only set for Method.
         bool isConstMethod = false;
         // Method declared static. Only set for Method.