Tolk silently accepts invalid hex digits in stringAddressToSlice, corrupting address literals

[Gusarich]

The Tolk compiler incorrectly accepts invalid hexadecimal characters (g-z, G-Z) in the stringAddressToSlice function during constant folding. Instead of reporting an error, it silently generates a corrupted address literal by incorrectly mapping invalid letters beyond f to out-of-range values.

Example Input:

fun onInternalMessage(): slice {
    return stringAddressToSlice("0:gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg");
}

Incorrect Optimized Output:

onInternalMessage PROC:<{
  // 
  x{8002020202020202020202020202020202020202020202020202020202020202021_} PUSHSLICE
}>

Cause:

• parse_raw_address interprets letters above f (such as g) as hex digits (16, 17, …) without range checking.
• These invalid values overflow the 4-bit nibble, corrupting the resulting address.

Impact:
Malformed address literals silently compile into corrupted constants, causing contracts to behave unexpectedly and potentially leading to severe logical and financial errors at runtime.

Expected Behavior:
The compiler must reject invalid hexadecimal literals beyond f explicitly, providing clear compile-time errors instead of silently corrupting address constants.

---

LLM Fuzzing discovery (see tact-lang/tact#3123)