fix: distinguish PCRE failure from a mismatch in Assert::regex()

preg_match() has three outcomes -- 1, 0 and false -- but regex() folded
false into the "no match" branch. An uncompilable pattern or an exhausted
PCRE limit therefore leaked a raw PHP warning out of the library and then
reported the misleading "The value ... does not match the expected pattern."

Check for false separately and report the pattern together with
preg_last_error_msg(), following the existing false === $x = nativeCall()
handling in Assert::strlen(). The caller's custom message is intentionally
not reused for that branch, since it describes a mismatch that never
happened. Matching values and genuine mismatches are unaffected.

src/Assert.php

@@ -1507,7 +1507,15 @@ class Assert
         static::string($value);
         static::string($pattern);
 
-        if (!\preg_match($pattern, $value)) {
+        if (false === $result = @\preg_match($pattern, $value)) {
+            static::reportInvalidArgument(\sprintf(
+                'The pattern %s could not be evaluated: %s.',
+                static::valueToString($pattern),
+                \preg_last_error_msg()
+            ));
+        }
+
+        if (0 === $result) {
             $message = self::resolveMessage($message);
             static::reportInvalidArgument(\sprintf(
                 $message ?: 'The value %s does not match the expected pattern.',