`PartLoadingTree::add` builds a containment tree of MergeTree parts during
`loadDataParts`. Parts are sorted by `(level, mutation)` descending so that
covering parts are inserted before the parts they contain. When a rolled-back
part in the tree intersects an incoming committed part two bugs were present:

**Bug 1 — wrong skip direction.**
The old code (`has_transaction_metadata`) checked whether either part has a
`txn_version.txt` file and unconditionally skipped the *incoming* part. When
the already-resident part was the rolled-back one, the committed incoming part
was silently discarded instead of replacing it.

**Bug 2 — orphans dropped after eviction.**
When the rolled-back resident is evicted, its children are orphaned. They
must be re-inserted via `add()` — together with the incoming committed part —
sorted by `(level, mutation)` descending so that the incoming part (typically
higher level) is placed into the tree *before* any orphan that belongs inside
it. Without this ordering an orphan at sibling level causes a spurious
`LOGICAL_ERROR` when the incoming part is re-inserted.

The crash observed in the stress test CI was caused by a third issue: the
old helper (`has_transaction_metadata`) returned `bool` — a plain
file-existence check. It could not distinguish between a definitively
rolled-back part, an in-flight transaction (`Tx::UnknownCSN`), and a read
error (e.g. an empty file read between shell `truncate` and `write`). When
neither part was definitively rolled-back, the code fell through to
`LOGICAL_ERROR`, which aborts the server in sanitizer builds.

CI: ClickHouse#100992

Replace the `bool`-returning helper with a 5-state `enum class RollbackStatus`
and rename the lambda to `read_txn_status`:

  `RolledBack`  — `creation_csn == Tx::RolledBackCSN` on disk
  `Committed`   — `creation_csn` is a known committed CSN on disk
  `NoMetadata`  — `txn_version.txt` absent (prehistoric/non-transactional part)
  `UnknownCSN`  — file present, `creation_csn == Tx::UnknownCSN` (in-flight)
  `Unreadable`  — file present but could not be parsed (corruption/partial write)

Intersection decision table (applied to both prev/next branches):

  `Unreadable` on either side       → `CORRUPTED_DATA` (not a code bug)
  incoming `RolledBack`             → skip incoming
  existing `RolledBack`             → evict existing; collect orphans + incoming
                                       sorted by `(level, mutation)` desc;
                                       re-add all via `add()`; `return`
  either `UnknownCSN`               → skip incoming (`loadDataPart` resolves later)
  both `NoMetadata` or `Committed`  → `LOGICAL_ERROR` (genuine bug / manual edit)

The `traverse` template body is moved inline into the header and `PartLoadingTree`
is made `public` so external tests can exercise it directly.

Add `tests/queries/0_stateless/04063_part_loading_tree_rollback_reparent.sh`.
The test manually constructs four part directories:

  `all_1_2_2_1` (1-2, L2, M1) — rolled-back parent; `txn_version.txt` holds
                                  `Tx::RolledBackCSN`; `creation_tid` uses
                                  `start_csn=2` (not `Tx::PrehistoricCSN`)
                                  so `wasInvolvedInTransaction` returns true
  `all_1_1_1_1` (1-1, L1, M1) — committed child; contained in 1-2 → inserted
                                  as a child of `all_1_2_2_1` during build
  `all_2_3_1_0` (2-3, L1, M0) — committed part; intersects `all_1_2_2_1`,
                                  triggering the eviction and re-parenting path

After `ATTACH TABLE`: `all_1_1_1_1` must be active (orphan successfully
re-parented) and `all_1_2_2_1` must not be active (rolled-back part discarded).

`txn_version.txt` is written atomically (`printf` to `.tmp` then `mv`) to
eliminate a stress-test race where the server reads the file in the window
between shell truncation and the actual write, producing an empty file and
a parse error (`Unreadable` state → `CORRUPTED_DATA` instead of server abort).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…loss

Addresses ClickHouse#100992 (comment)

Previously, when an intersecting tree-resident part had `creation_csn = Tx::UnknownCSN`
on disk, the incoming committed peer was dropped from the loading tree. The plan
was that `loadDataPart` would resolve the CSN afterwards. But `loadDataPart` only
runs on the top-level nodes of the loading tree, and the dropped peer was never
re-introduced — so if the in-flight transaction turned out to be rolled back, the
committed peer was permanently absent for that startup (data only became visible
after a second restart, once `Tx::RolledBackCSN` was persisted to disk).

`read_txn_status` now consults `TransactionLog` when the on-disk CSN is unresolved,
mirroring the logic of `VersionMetadata::tryGetCSN`: if the tid has no CSN and no
running transaction, it's treated as rolled back. The `UnknownCSN` `RollbackStatus`
arm now only fires for transactions that are genuinely still running (an unusual
case during `loadDataParts`), and the rolled-back arm correctly evicts the dead
part and keeps the committed peer.

…rtLoadingTree::add`

Addresses ClickHouse#100992 (comment)

A committed part can be silently buried under a rolled-back ancestor when the
ancestor contains it (rather than just intersects). The previous code only
checked rollback status in the `isDisjoint == false` (intersection) branch, so
when an incoming committed part descended through the `contains` branch into a
rolled-back ancestor it became a "covered" child and was loaded as `Outdated`
instead of active — invisible to queries until the next restart resolved the
ancestor's `creation_csn` to `Tx::RolledBackCSN` on disk.

Add the same eviction check in both `contains` branches (`prev` and `next`).
On match, the helper `evict_rolled_back_and_reinsert` collects the rolled-back
node's orphaned descendants, sorts them with the incoming part by
`(level, mutation)` descending, and re-inserts the lot — so any new
top-level ancestor is added before its descendants and re-parenting happens
cleanly.

Also extract the inline eviction code from the two intersection branches into
the same helper, removing the duplicated logic.

New regression test `04241_part_loading_tree_rollback_contains` exercises the
`R-contains-{C, N}` topology that triggered a `LOGICAL_ERROR` (or silent data
loss, depending on the levels) before this fix.

Addresses https://github.com/ClickHouse/ClickHouse/actions/runs/26031517236
(`test_transactions/test.py::test_rollback_unfinished_on_restart{1,2}`
fail with `len(res) == 5` because the rolled-back mutation parts are
not in `system.parts`) and
ClickHouse#100992 (comment)
(bot flags an `UnknownCSN` race in the same branch).

The prior commit (`7587b5c5101`) added a rollback check in the `contains`
branches and evicted the ancestor when found rolled-back. But the rest of
the load path already handles this — `MergeTreeData::loadDataPartsFromDisk`
detects that a top-level part was demoted to `Outdated` (e.g. by
`loadDataPart`'s `creation_csn == Tx::RolledBackCSN` check) and pushes its
children onto `parts_to_load` to be loaded as `Active`. So the eviction in
`PartLoadingTree::add` was redundant, and worse it removed the rolled-back
parts from `system.parts` entirely, which the integration test relies on.

This commit keeps:
- the intersection-branch eviction (the original PR's fix — there the
  promotion mechanism does not apply because the committed peer is a
  sibling, not a child, of the rolled-back tree-resident);
- the eager `UnknownCSN` resolution in `read_txn_status`;
- the helper `evict_rolled_back_and_reinsert` (still used by both
  intersection branches);
- `04241_part_loading_tree_rollback_contains` — the test now passes via
  the existing promotion mechanism rather than tree-level eviction, but
  the assertion remains the same (committed children are active).

…ee-rollback-detection