Galera maintains "certification index" to help in tracking dependencies between transactions. This dependency information makes it possible e.g. to enable parallel applying with row level granularity in slave side.
This test will cause several table and row level entries to be appended in the certification index, and this probably accounts for the observed memory image growth. Galera does periodical pruning for the index, but it will be delayed process and does not show here.
To test for memory leaks, it makes sense to run long term SQL load and monitor that memory image will saturate at certain level. Or alternatively run under valgrind.

Looks like false positive, long term test shows no trails of memory leak

>> Looks like false positive, long term test shows no trails of memory leak

This is because the bug was not about a memory leak, otherwise it would have said so. It was about excessive memory use: a modest operation (I do consider 128K rows is a rather modest number in the real world), which normally does not take anything above what the server already occupies, in Galera context requires additional 250+ Mb, even if it's only temporarily; and that's on top of extra 250 Mb which it takes just to start an empty node.
If you don't consider it a problem, so be it, but I can say right away, based on complaints we'd heard before about any slightly increased footprint, that users are not going to like it unless it's configurable and can be avoided or reasonably and explicitly limited (which it might still be, and I just don't know about it).

A fancy corollary: probably we won't even be able to run standard MTR test on a server with wsrep.

Example (the original test case is main.multi_update2, it is not applicable as it is with $1=19, because it uses 2M rows while the hard limit is 1M rows. So, we reduce it to $1=18 and $1=17, below are the numbers of the comparative test)

with wsrep
------------------

MTR command-line options:
-mysqld=tmp_table_size=1024 --mysqld=innodb --mysqld=default-storage-engine=innodb --mysqld=innodb_autoinc_lock_mode=2 --mysqld=innodb_locks_unsafe_for_binlog=1 --mysqld=innodb_flush_log_at_trx_commit=0 --mysqld=innodb_doublewrite=0 --mysqld=binlog-format=row --mysqld=log-bin=master-bin --mysqld=wsrep_provider=/home/elenst/galera-23.2.1-src/libgalera_smm.so --mysqld=wsrep_cluster_address=gcomm://?'gmcast.listen_addr=tcp://127.0.0.1:4567' --mysqld=wsrep_max_ws_size=4G --mysqld=-wsrep_max_ws_rows=1M --testcase-timeout=300

$1=17 (500K rows)
Execution time: 558 sec, grows up to 2 Gb

457 elenst 20 0 557m 235m 12m S 34 2.9 0:03.44 mysqld
...
457 elenst 20 0 2035m 1.7g 57m S 127 22.3 8:39.71 mysqld

$1=18 (1M rows)
Execution time: 938 sec, grows up to 4 Gb

866 elenst 20 0 606m 247m 12m S 77 3.1 0:07.67 mysqld
...
866 elenst 20 0 3932m 3.5g 94m S 200 45.2 14:35.75 mysqld

Same build, without wsrep
------------------

MTR command-line options (all the same minus wsrep):
-mysqld=tmp_table_size=1024 --mysqld=innodb --mysqld=default-storage-engine=innodb --mysqld=innodb_autoinc_lock_mode=2 --mysqld=innodb_locks_unsafe_for_binlog=1 --mysqld=innodb_flush_log_at_trx_commit=0 --mysqld=innodb_doublewrite=0 --mysqld=binlog-format=row --mysqld=-log-bin=master-bin --testcase-timeout=300

$1 = 17 (500K rows)
Execution time: 299 sec, stays inside initial 400+ Mb

1093 elenst 20 0 403m 195m 6140 S 4 2.4 0:00.37 mysqld
...
1093 elenst 20 0 283m 85m 10m S 100 1.1 4:36.88 mysqld

$1 = 18 (1M rows)
Execution time: 465 sec, stays inside initial 400+ Mb

981 elenst 20 0 403m 195m 6140 S 3 2.4 0:00.34 mysqld
...
981 elenst 20 0 404m 209m 10m S 147 2.6 7:01.88 mysqld