CLEAR COLUMN is silently skipped when combined with RENAME COLUMN of the same column in one ALTER statement

Start with AlterCommands::prepare and splitAndModifyMutationCommands in src/Storages/MergeTree/MutateTask.cpp, then reproduce the combined RENAME COLUMN and CLEAR COLUMN statement with Wide and Compact parts. Compare the resulting data and mutation state; done means the renamed column is cleared consistently and the relevant regression test passes.

TL;DR: ALTER TABLE t RENAME COLUMN a TO c, CLEAR COLUMN c in a single statement reports success (mutations_sync = 2 returns, system.mutations.is_done = 1, no error), but the column data is not cleared: the old values survive under the new name. A user who relies on CLEAR COLUMN to destroy data (for example for privacy compliance) keeps the data on disk without any indication.

Describe what's wrong

When a RENAME COLUMN and a CLEAR COLUMN of the same column are combined in one ALTER statement, the CLEAR is silently skipped. On 25.8 this affects both Compact and Wide parts; on current master the Compact path clears correctly while the Wide path still keeps the old values, so the same statement gives different data depending on the part format.

The reverse order (CLEAR COLUMN a, RENAME COLUMN a TO c) is the already-reported #76485 (it fails with an exception). This report is about the rename-first order, which does not fail — it silently does nothing.

Does it reproduce on the most recent release?

Yes, reproduced on 25.8 (both part formats) and on master 26.9.1.1 (Wide parts).

How to reproduce

CREATE TABLE t (k Int32, a Int32) ENGINE = MergeTree ORDER BY k SETTINGS min_bytes_for_wide_part = 0;
INSERT INTO t VALUES (1, 7);
ALTER TABLE t RENAME COLUMN a TO c, CLEAR COLUMN c SETTINGS mutations_sync = 2;
SELECT c FROM t; -- returns 7, expected 0

https://fiddle.clickhouse.com/bbe4fa81-dbcc-4989-a84f-907e19882194 (25.8: both Wide and Compact return 7)

Controls:

1. The same two commands as separate ALTER statements clear correctly (c = 0).
2. On master 26.9.1.1, the same statement on a Compact part clears correctly (c = 0); a Wide part keeps c = 7.
3. Scale check on master, Wide part: after inserting 100000 rows with sum(a) = 5009950000, the combined statement returns success and sum(c) is still 5009950000 (expected 0). The values survive DETACH TABLE / ATTACH TABLE.
4. CLEAR COLUMN IF EXISTS c after the rename is skipped the same way.
5. ReplicatedMergeTree behaves the same (Wide part keeps the value, Compact part clears).

Expected behavior

The CLEAR COLUMN clears the renamed column: subsequent reads return the column type's default value, and the on-disk data of the old values is rewritten.

Additional context

system.mutations shows the mutation as done with an empty latest_fail_reason, so there is no signal that the clear did not happen. The open PR #117825 makes AlterCommands::prepare advance its working snapshot per command and reworks the same-batch rename handling in splitAndModifyMutationCommands (src/Storages/MergeTree/MutateTask.cpp); its new test expects this statement to clear, so it appears to fix the master Wide-part face, but released versions are affected today.