Describe the problem

The experimental ALTER COLUMN TYPE has an egregious bug. We seemingly don't do anything about indexes which store the column. This leads to these indexes persisting with the old column even after it is not in the table. For various reasons, this sort of worked out surprisingly well because the implementation of the various column ordinal maps wouldn't find the column and stored columns end up, mostly, being an optimization.

To Reproduce

The repro from #72718 (comment) demonstrates it.

Expected behavior
We should have rewritten the index.

Additional context

This leaves us in a sticky situation. These indexes might exist in the wild. Ideally we'd properly validate that all the columns in an index exist in the table descriptor. I'm inclined to add such validation now. In the meantime, existing descriptors will be broken and we'll need to drop the index.

#72718 is caused by this and #72676 reveals it. The way that it gets revealed, which is rather horrific, is that there's a different behavior in the small and large FastIntMap. If the value does not exist in small, you'll get -1, false, but if it does not exist in large, you'll get 0, false. See