[Bug]: UPDATE moving a row across partitions fails with ExpectedEOB

### Is there an existing issue for the same bug?

- [x] I have checked the existing issues.

### Environment

- Branch: latest `main`
- Commit: `60d28f8ecb93ae512da6af4a2915b204a373bd42`
- Topology used for verification: two CN services, results checked from both coordinators.

### Actual Behavior

An ordinary `UPDATE` that changes a partition key so that the row must move to a different physical partition fails with the internal error `ExpectedEOB`.

The statement does not partially commit: the original row remains visible on both CNs. However, valid SQL cannot perform the partition-key update.

Minimal range-partition repro:

```sql
drop database if exists partition_key_update_eob;
create database partition_key_update_eob;
use partition_key_update_eob;

create table t (
id int primary key,
v int
) partition by range columns(id) (
partition p0 values less than (1000),
partition pmax values less than (MAXVALUE)
);

insert into t values (1, 10);
update t set id = 1001 where id = 1;
-- ERROR: ExpectedEOB

select count(*), min(id), sum(v) from t;
-- 1, 1, 10 -- original row remains; row (1001, 10) was not written
```

The same result is reproduced for a hash partition:

```sql
create table t (id int primary key, v int)
partition by hash(id) partitions 4;
insert into t values (1, 10);
update t set id = 2 where id = 1;
-- ERROR: ExpectedEOB
```

It is not limited to changing a primary-key column. A table with `primary key(id, p)` partitioned by `hash(p)`, with a secondary index, also fails when `p` is changed to a different partition.

### Verification

- Range-partition single-row move: 20/20 failed with `ExpectedEOB`; the original row remained intact.
- Hash-partition single-row move: 20/20 failed with `ExpectedEOB`; the original row remained intact.
- Range-partition multi-row move across several partitions: 30/30 failed with `ExpectedEOB`; both CNs observed the original three rows and no moved rows.
- Controls passed: updating a non-partition column across multiple partitions, and changing a partition key while it stays in the same range partition, both commit normally. A 50-round multi-partition update maintaining a unique key and a secondary index also remained correct on both CNs.

### Expected Behavior

The update should atomically delete the old physical-partition row and insert the new physical-partition row, while keeping indexes consistent.

### Initial Code Observation

`pkg/sql/colexec/multi_update/multi_update_partition.go` prunes the update batch using the post-update partition key, then maps the full update context to that destination relation. A cross-partition update needs the delete side to address the source partition and the insert side to address the destination partition. The current single-relation routing appears consistent with the observed `ExpectedEOB`; this is an implementation hypothesis, not a confirmed root cause.