A corrupt blocks/index can stop the node at startup. A last block file number of -1 makes it read before the start of a vector. A very large one makes it allocate and read that many file infos. A block without a parent, or with a parent at the wrong height, hits the assert in CBlockIndex::GetAncestor.
I reject these entries on load, so init reports the usual database error and suggests -reindex. A last file without stored info is still accepted when the file before it has info, because running out of disk space while opening a new file leaves that state. The new unit tests fail on master, and the reindex, pruning and assumeutxo functional tests pass. #32427 would replace this database and derive the last file number from its entries.
This is one of several PRs from a large audit of Bitcoin Core that I did with the help of LLM tools. The audit produced its evidence all at once, which is why the PRs arrive together. I understand each change fully and will answer review questions myself.
