fix(mysql): use gtid_binlog_pos for MariaDB CDC start position (#4523)

## Problem

Customers on MariaDB CDC hit:

```
ERROR 1236 (HY000): Error: connecting slave requested to start from GTID
0-1026536087-10250614208, which is not in the master's binlog. Since the
master's binlog contains GTIDs with higher sequence numbers, it probably
means that the slave has diverged due to executing extra erroneous transactions
```

## Terminology

- `@@gtid_binlog_pos` is GTID of the last event written to the binary
log
- `@@gtid_slave_pos` exists only on replica servers and contains the
last replicated GTID. It will write this event to its own binlog ONLY if
`log_slave_updates=ON`.
- `@@gtid_current_pos` is the max of `@@gtid_binlog_pos` and
`@@gtid_slave_pos`.

## Current behaviour

Now peerdb uses `@@gtid_current_pos` as a starting cdc point. In most
cases it's fine. But problems begin if you promote a replica that had
`log_slave_updates=OFF` to become a primary (by applying smth like `STOP
SLAVE; RESET SLAVE;`). In that case replica's `@@gtid_slave_pos` is not
zero and therefore it can be returned as a value of `@@gtid_current_pos`
-> which leads to a situation when we try to start replication with GTID
which has never been written to that replica binlog.

## Solution

We must always use `@@gtid_binlog_pos`, which is the source of truth for
current GTID that exists on the server. For us it doesn't matter whether
the server is a replica or primary or has been a replica before. We just
need to know what is the current GTID from its own binlog.

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: dtunikov

flow/connectors/mysql/mysql.go

@@ -467,7 +467,7 @@ func (c *MySqlConnector) GetMasterGTIDSet(ctx context.Context) (mysql.GTIDSet, e
 	var query string
 	switch c.Flavor() {
 	case mysql.MariaDBFlavor:
-		query = "select @@gtid_current_pos"
+		query = "select @@gtid_binlog_pos"
 	default:
 		query = "select @@GLOBAL.gtid_executed"
 	}