[client-v2] Compiled POJO setter emits invalid bytecode (VerifyError) when the column type does not match the primitive field type

使用所示的 client-v2 POJO 查询重现该失败，然后检查 SerializerUtils.compilePOJOSetter 和 binaryReaderMethodForType，包括 longToOpcode、floatToOpcode 和 doubleToOpcode 分支。完成的标准是：不匹配的 primitive binding 会生成带有 Java 窄化或拓宽转换的可验证 setter，并且 Number 值列可以读入 primitive 字段而不会出现 VerifyError。

Describe the bug

client-v2 compiles a POJO field setter into bytecode (SerializerUtils.compilePOJOSetter). When the column type
and the POJO field's primitive type do not match exactly, the generated class is invalid and reading fails with
java.lang.VerifyError (thrown when the compiled setter class is first linked, i.e. on the first row read).

Two distinct groups of combinations are affected.

1. The value left on the stack is not converted to the setter's primitive type.
binaryReaderMethodForType only computed a conversion opcode for a few reader/field combinations
(longToOpcode, floatToOpcode and doubleToOpcode return -1 for byte/short/char/boolean, and the
Int8/UInt8/Int16/Enum8/Enum16/Bool branches computed no conversion at all). So, for example:

• an Int64, UInt32, Float32, Float64 or BFloat16 column bound to a byte, short, char or boolean field
• an Int8, UInt8, Int16, Enum8, Enum16 or Bool column bound to a long, float or double field

leave a value of the wrong type on the operand stack for the setter descriptor, and the generated class does not verify.

2. A primitive field bound to a column that is not read into a primitive.
The generic branch emits LDC of a class constant for the target type and CHECKCAST with its internal name.
For a primitive target that produces a class constant named "I"/"J" and a CHECKCAST int, and the value read
by readValue (an Object) is passed to a primitive setter descriptor. So Int128, UInt128, Int256, UInt256
and Decimal* columns cannot be read into a primitive field at all, even though the value is a Number.

Steps to reproduce

public class Pojo {
    private short v;
    public short getV() { return v; }
    public void setV(short v) { this.v = v; }
}

String sql = "SELECT toInt64(300) AS v";                 // also: toFloat64(-2.7), toInt8(-5) into a long field, ...
TableSchema schema = client.getTableSchemaFromQuery(sql);
client.register(Pojo.class, schema);
client.queryAll(sql, Pojo.class, schema);                // -> java.lang.VerifyError

The same happens with SELECT toInt128(-2) AS v or SELECT toDecimal64(123.45, 2) AS v bound to a long/double
field (group 2).

Expected behaviour

The value is converted to the field's primitive type following Java's narrowing/widening rules (as already happens
for an Int32 column bound to a byte field), and a Number-valued column can be read into a primitive field.

Error log

java.lang.VerifyError
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	...
	at com.clickhouse.client.api.data_formats.internal.SerializerUtils.compilePOJOSetter(SerializerUtils.java:...)

Configuration

• Client version: main (0.11.0-rc1)
• Language: Java
• Client: client-v2 (POJO binding / queryAll(sql, Pojo.class, schema))