btck_chainstate_manager_process_block stores blocks that bitcoind skips when it did not request them. It processes every block as if requested. A block is therefore stored even if it has less work than the tip, is more than 288 blocks ahead of it, is below the minimum chain work, or was pruned before. I document that a caller taking blocks from untrusted sources must apply these checks itself. I leave the header path undocumented, as discussed in #33822 (review). #34022, which proposed removing the flag, was closed. Blocks differ because force_processing changes what is stored.
The second commit documents two preconditions that abort the process. btck_precomputed_transaction_data_create aborts when spent_outputs is set and its length differs from the input count. A nested btck_chainstate_manager_import_blocks call on the same chainstate manager also aborts. I checked both aborts with a small program against the library. The kernel library builds, and the whitespace and commit-message lints pass.
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.
