BUG #18238: Cross-partitition MERGE/UPDATE with delete-preventing trigger leads to incorrect memory access

The following bug has been logged on the website:

Bug reference:      18238
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 16.1
Operating system:   Ubuntu 22.04
Description:

When the following query:
CREATE TABLE t (a int) PARTITION BY LIST (a);
CREATE TABLE tp1 PARTITION OF t FOR VALUES IN (1);
CREATE TABLE tp2 PARTITION OF t FOR VALUES IN (2);
INSERT INTO t VALUES (1);

CREATE FUNCTION tf() RETURNS TRIGGER LANGUAGE plpgsql AS
  $$ BEGIN RETURN NULL; END; $$;

CREATE TRIGGER tr BEFORE DELETE ON t
  FOR EACH ROW EXECUTE PROCEDURE tf();

MERGE INTO t USING t st ON TRUE WHEN MATCHED THEN UPDATE SET a = 2;

executed under Valgrind, an incorrect memory access detected:
2023-12-09 13:31:37.178 UTC|law|regression|65744207.29a672|LOG:  statement:
MERGE INTO t USING t st ON TRUE
        WHEN MATCHED THEN UPDATE SET a = 2;
==00:00:00:08.207 2729586== Conditional jump or move depends on
uninitialised value(s)
==00:00:00:08.207 2729586==    at 0x43DB3A: ItemPointerIsValid
(itemptr.h:85)
==00:00:00:08.207 2729586==    by 0x43DB3A: ItemPointerGetOffsetNumber
(itemptr.h:126)
==00:00:00:08.207 2729586==    by 0x43DB3A:
ItemPointerIndicatesMovedPartitions (itemptr.h:200)
==00:00:00:08.207 2729586==    by 0x43DB3A: ExecMergeMatched
(nodeModifyTable.c:3051)
==00:00:00:08.207 2729586==    by 0x43DE41: ExecMerge
(nodeModifyTable.c:2762)
==00:00:00:08.207 2729586==    by 0x43E846: ExecModifyTable
(nodeModifyTable.c:3850)
==00:00:00:08.207 2729586==    by 0x4106FE: ExecProcNodeFirst
(execProcnode.c:464)
==00:00:00:08.207 2729586==    by 0x408CC1: ExecProcNode (executor.h:273)
==00:00:00:08.207 2729586==    by 0x408CC1: ExecutePlan (execMain.c:1670)
==00:00:00:08.207 2729586==    by 0x408E84: standard_ExecutorRun
(execMain.c:365)
==00:00:00:08.207 2729586==    by 0x408F5E: ExecutorRun (execMain.c:309)
==00:00:00:08.207 2729586==    by 0x5F032E: ProcessQuery (pquery.c:160)
==00:00:00:08.207 2729586==    by 0x5F0EBD: PortalRunMulti (pquery.c:1277)
==00:00:00:08.207 2729586==    by 0x5F1457: PortalRun (pquery.c:791)
==00:00:00:08.207 2729586==    by 0x5ED5F4: exec_simple_query
(postgres.c:1274)
==00:00:00:08.207 2729586==    by 0x5EF502: PostgresMain (postgres.c:4637)
==00:00:00:08.207 2729586==  Uninitialised value was created by a stack
allocation
==00:00:00:08.207 2729586==    at 0x3D8663: GetTupleForTrigger
(trigger.c:3283)
==00:00:00:08.207 2729586==

Without Valgrind, I saw a failed assertion:
#5  0x00005609515b766e in ExceptionalCondition
(conditionName=conditionName@entry=0x56095161309a
"ItemPointerIsValid(pointer)", fileName=fileName@entry=0x56095163dc18
"../../../src/include/storage/itemptr.h", lineNumber=lineNumber@entry=126)
at assert.c:66

and
ERROR:  could not open file "base/16384/16393.1" (target block 3081245700):
previous segment is only 1 blocks

Reproduced on REL_15_STABLE .. master.
First bad commit for this anomaly is 9321c79c8.