Optimize UINT64/UINT128 decoding to avoid BigInteger allocation

For UINT64/UINT128 values less than 8 bytes (which fit in long's positive
range), decode directly to long instead of BigInteger when the target is a
typed field. This avoids unnecessary BigInteger object allocation for common
cases like UINT64 values under 2^56.

Maintains backward compatibility by preserving BigInteger return type for
Object.class targets (e.g., Map decoding).

Performance impact:
- UINT64(500) into Long field: decodes as long (no BigInteger allocation)
- UINT64(500) into Object/Map: still returns BigInteger (backward compatible)
- UINT64 >= 8 bytes: always uses BigInteger (correctness)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: oschwald

src/main/java/com/maxmind/db/Decoder.java

@@ -244,6 +244,13 @@ private <T> Object decodeByType(
                 return coerceFromInt(this.decodeInt32(size), cls);
             case UINT64:
             case UINT128:
+                // Optimization: for typed fields, avoid BigInteger allocation when
+                // value fits in long. Keep Object.class behavior unchanged for
+                // backward compatibility.
+                if (size < 8 && !cls.equals(Object.class)) {
+                    return coerceFromLong(this.decodeLong(size), cls);
+                }
+                // Size >= 8 bytes or Object.class target: use BigInteger
                 return coerceFromBigInteger(this.decodeBigInteger(size), cls);
             default:
                 throw new InvalidDatabaseException(