mview: reduce unnecessary writes in handle-changed update path

## Enhancement
Reduce unnecessary mlog writes in the handle-changed update path by propagating `touched` column information.

### Background

PR #66204 introduced mlog DML writing with a `shouldLogUpdate(touched)` optimization: when an UPDATE only modifies columns that are *not* tracked by the mlog, the mlog write is skipped. However, this optimization only applies in the `UpdateRecord` path (handle-unchanged updates).

For handle-changed updates (e.g., UPDATE that modifies the primary key, or INSERT ON DUPLICATE KEY UPDATE that changes the PK), the executor decomposes the operation into `RemoveRecord(old)` + `AddRecord(new, IsUpdate)`. In this path, **neither** `AddRecord` nor `RemoveRecord` calls `shouldLogUpdate` — they always write to the mlog unconditionally.

### Current Behavior

When a handle-changed UPDATE only modifies the primary key but does not touch any mlog-tracked columns, the mlog still receives two rows (old + new). This is correct but wasteful — the downstream materialized view refresh will process mlog rows that represent no meaningful change to the tracked data.

### Expected Improvement

Propagate `touched` column information into the handle-changed path so that `shouldLogUpdate` can be consulted before writing mlog rows.

### Related

- #18023
- #66204

Start by reviewing PR #66204 and tracing the handle-changed path through RemoveRecord(old) and AddRecord(new, IsUpdate), alongside UpdateRecord and shouldLogUpdate(touched). Propagate the touched-column information so handle-changed updates consult shouldLogUpdate before writing mlog rows; done means changes only to untracked columns avoid unnecessary writes while tracked changes remain logged.

Written by the indexing model from the issue text.