[Bug]: REPLACE on partitioned table with secondary index returns ExpectedEOB

## Bug description

`REPLACE` on a partitioned table with an ordinary secondary index fails during transaction commit with `ExpectedEOB`. The statement is rolled back.

Reproduced on `main` at `6eee64625e7e2cefd0f3dfeb61606f637111e057` while validating #28312.

## Reproduction

```sql
create database partition_replace_index_repro;
use partition_replace_index_repro;

create table p (
id int primary key,
body varchar(30),
key bi(body)
) partition by hash(id) partitions 2;

insert into p values (1, 'one'), (2, 'two');
replace into p values (2, 'new');
select * from p order by id;
```

## Actual behavior

The `REPLACE` reaches commit, returns `ExpectedEOB`, and rolls back. The row with `id = 2` remains unchanged.

## Expected behavior

The statement succeeds atomically and replaces `(2, 'two')` with `(2, 'new')`, while keeping the secondary index consistent.

## Controls

- The same partitioned table without the secondary index completes `REPLACE` successfully.
- The same indexed table without partitioning completes `REPLACE` successfully.
- `UPDATE p SET body = 'new' WHERE id = 2` succeeds on the partitioned indexed table.

The failure therefore requires the combination of partition routing, ordinary secondary-index maintenance, and the `REPLACE` delete/insert path.