TRUNCATE CASCADE is slower in the declarative schema changer

**Describe the problem**

Despite recent optimizations (https://github.com/cockroachdb/cockroach/issues/171905) , `TRUNCATE CASCADE` is still slower in the declarative schema changer compared to the legacy schema changer. The difference gets worse as the number of tables and secondary indexes affected by truncate increase.

**To Reproduce**

Run `pkg/bench/rttanalysis/truncate_bench_test.go` or run the following sql.

```sql
--- to enable dep rule logging: SELECT crdb_internal.set_vmodule('registry=2');
CREATE TABLE parent (id INT8 PRIMARY KEY, u INT8 UNIQUE) WITH (schema_locked = false);
CREATE TABLE child0 (id INT8 PRIMARY KEY, u INT8 UNIQUE, p INT8, FOREIGN KEY (p) REFERENCES parent (id)) WITH (schema_locked = false);
CREATE TABLE child1 (id INT8 PRIMARY KEY, u INT8 UNIQUE, p INT8, FOREIGN KEY (p) REFERENCES parent (id)) WITH (schema_locked = false);
CREATE TABLE child2 (id INT8 PRIMARY KEY, u INT8 UNIQUE, p INT8, FOREIGN KEY (p) REFERENCES parent (id)) WITH (schema_locked = false);
CREATE TABLE child3 (id INT8 PRIMARY KEY, u INT8 UNIQUE, p INT8, FOREIGN KEY (p) REFERENCES parent (id)) WITH (schema_locked = false);
CREATE TABLE grandchild0 (id INT8 PRIMARY KEY, u INT8 UNIQUE, c INT8, FOREIGN KEY (c) REFERENCES child0 (id)) WITH (schema_locked = false);
CREATE TABLE grandchild1 (id INT8 PRIMARY KEY, u INT8 UNIQUE, c INT8, FOREIGN KEY (c) REFERENCES child1 (id)) WITH (schema_locked = false);
CREATE TABLE grandchild2 (id INT8 PRIMARY KEY, u INT8 UNIQUE, c INT8, FOREIGN KEY (c) REFERENCES child2 (id)) WITH (schema_locked = false);
CREATE TABLE grandchild3 (id INT8 PRIMARY KEY, u INT8 UNIQUE, c INT8, FOREIGN KEY (c) REFERENCES child3 (id)) WITH (schema_locked = false);
TRUNCATE TABLE parent CASCADE;
```

**Impact**
Even though the optimizations from https://github.com/cockroachdb/cockroach/issues/171905 made this operation ~1.64x faster, it's still 2x slower than the legacy schema changer. Note that the difference is small in terms of wall clock time.
| Variant | Time/op | Mem/op | Allocs/op |
|---|---:|---:|---:|
| declarative (before opt) | 131.53 ms | 68.89 MB | 485,014 |
| declarative (after opt) | 80.14 ms | 54.72 MB | 403,364 |
| legacy | 38.03 ms | 40.59 MB | 257,260 |

| Comparison | Time | Mem | Allocs |
|---|---:|---:|---:|
| opt vs before-opt (declarative) | **−39.1%** (1.64× faster) | −20.6% | −16.8% |
| declarative (after opt) vs legacy | 2.11× slower | 1.35× | 1.57× |
| declarative (before opt) vs legacy | 3.46× slower | 1.70× | 1.89× |

**Potential Fix**
Investigate and optimize the DSC planner. The analysis shows that 20% of the time is spent on planning which is considerable for this operation.

Jira issue: CRDB-65741

Start with pkg/bench/rttanalysis/truncate_bench_test.go and reproduce the declarative-versus-legacy timings using the SQL example. Profile the declarative schema changer planner, focusing on the reported planning time, then rerun the benchmark; done means the declarative TRUNCATE CASCADE path is measurably closer to the legacy path without regressions.

Written by the indexing model from the issue text.