Bug(expr): isdigit/isalpha/isalnum are mutually inconsistent on Unicode-numeric, non-ASCII-digit input

[uberware]

Summary

For '٣' (ARABIC-INDIC DIGIT THREE, U+0663): isdigit → false, isalpha → false, yet
isalnum → true. isalnum is not isalpha OR isdigit in this implementation, and RFC
0006 gives no indication the three should disagree.

Versions

• openjd-model 0.11.1 and 0.11.2 from PyPI
• openjd-rs main at 1a89f3a — still reproduces

Reproduction

from openjd.expr import parse_expression
for fn in ("isdigit", "isalpha", "isalnum"):
    r = parse_expression(f"{fn}('٣')").evaluate_with_metrics()
    print(fn, "->", str(r.value))
# isdigit -> false
# isalpha -> false
# isalnum -> true

Why this is a bug

Whichever character-class convention is intended (ASCII-only or full Unicode), the three
predicates should compose: a character that is neither alphabetic nor a digit cannot be
alphanumeric. Today a guard like
isdigit(Param.X) and int(Param.X) and a guard written with isalnum disagree about the
same input.