128 used as a bare literal in PHP & Clojure obfuscation regexes (should be .{128,}) #28

The *_obfuscation_declarations rules use a pattern-regex to flag suspicious identifier names. In
11 of 13 languages the "very long name" test is written as .{128,} (128 characters or more):

csharp:      ^\d|(.)\1{3,}|.{128,}|^_0x|...
dart:        ^\d|(.)\1{3,}|.{128,}|^_0x|...
go:          ^\d|(.)\1{3,}|.{128,}|^_0x|...
java:        ^\d|(.)\1{3,}|_0x|.{128,}|...
javascript:  ^\d|(.)\1{3,}|.{128,}|^_0x|...
lua/python/ruby/rust/scala: same `.{128,}`

But PHP and Clojure use a bare 128:

php:      ^\$\d|(.)\1{3,}|128|_0x|([^a-zA-Z0-9_$\->])
clojure:  ^\d|(.)\1{3,}|128|^_0x|([^a-zA-Z0-9_.\-\/])

Impact

A bare 128 matches any identifier that merely contains the substring "128", so ordinary names are
flagged as obfuscated; for example $aes128key, $buffer128, $sha128, $utf128, $base128. That
undercuts the README's stated goal of including "only rules with low false-positive rates", and the
severity for these rules is ERROR.

Note the PHP file's second regex (the define(...) branch, line 25) already uses .{128,} correctly,
which suggests the first one is simply a typo.

Suggested fix

-  pattern-regex: ^\$\d|(.)\1{3,}|128|_0x|([^a-zA-Z0-9_$\->])
+  pattern-regex: ^\$\d|(.)\1{3,}|.{128,}|_0x|([^a-zA-Z0-9_$\->])

and the same substitution in obfuscation/clojure/clojure_obfuscation_declarations.yml.

Minor, possibly intentional: the _0x alternative is anchored (^_0x) in 10 languages but unanchored
(_0x) in PHP, Java and Ruby. If the anchoring is meant to be consistent, those three are the outliers.