This does look to be a legitimate bug. This would apply to any character
set where charset_info_st field escape_with_backslash_is_dangerous is
true, which currently is: big5, cp932, gbk, sjis.

The problem here is that string parameters coming from prepared
statements are being converted into 0xHHHH form indiscriminately in
append_query_string, which is producing the string to be binlogged for
statement-based replication. While that works okay for insertion of
strings into string fields, it causes the
conversion-from-string-to-integer which is happening on the master for
insertion of a string into an integer field to not be happening on the
slave, since 0xHHHH form is more properly an integer than a string.

This can be captured by setting a breakpoint at str_to_hex and running
this test case:

DROP TABLE IF EXISTS t;
CREATE TABLE t (id INT NOT NULL AUTO_INCREMENT, a INT, PRIMARY KEY(id));
SET NAMES gbk;
PREPARE STMT FROM 'INSERT INTO t (a) VALUES (?)';
SET @a = '1';
EXECUTE STMT USING @a;

Using SHOW BINLOG EVENTS shows that the problem is from the server (binlogging) side:

    Log_name: 0.000001
         Pos: 450
  Event_type: Query
   Server_id: 1
End_log_pos: 544
        Info: use `test`; INSERT INTO t (a) VALUES (0x31) 

0xHHHH is a MySQL extension. It's a hybrid thing.
It can behave as a number and a string depending on context.

Binary log could use the X'HHHH' notation instead:
INSERT INTO t1 VALUES (a) VALUES (X'31');

which is an SQL standard thing, and which must always be a string.

However, it seems the behaviour of X'HHHH' and of 0xHHHH
is exactly the same, and X'HHHH' can also act as a number:

drop table if exists t1;
create table t1 (id int);
insert into t1 values (x'31'),(0x31),(concat(0x31));
select * from t1;
+------+
| id   |
+------+
|   49 | <-- wrong
|   49 | <-- ok
|    1 | <-- ok
+------+ 

Proposed fix:
1. Fix X'HHHH' to work always as string.
2. Fix binlog to use X'HHHH'