Bogus debug assertion failure in multi-batch recovery while parsing FILE_ records

mleich produced a data set where a server was running with innodb_log_file_size=96M and innodb_buffer_pool_size=6M. After the server was killed and restarted, it would crash like the following (from a local run using a copy of the data, using an even smaller buffer pool):

2024-09-10 12:24:46 0 [Note] InnoDB: Small buffer pool size (5.000MiB), the flst_validate() debug function can cause a deadlock if the buffer pool fills up.

2024-09-10 12:24:46 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=19308819

2024-09-10 12:24:46 0 [Note] InnoDB: Ignoring data file './test/#sql-alter-14a918-20.ibd' with space ID 19. Another data file called ./test/t6.ibd exists with the same space ID.

2024-09-10 12:24:46 0 [Note] InnoDB: Multi-batch recovery needed at LSN 21507736

mariadbd: /mariadb/10.11/storage/innobase/log/log0recv.cc:2849: recv_sys_t::parse_mtr_result recv_sys_t::parse(source&, bool) [with source = recv_buf; bool store = false]: Assertion `!file_checkpoint || space_id == TRX_SYS_SPACE || srv_is_undo_tablespace(space_id)' failed.

The debug assertion fails, because we are expecting to know the file name of the tablespace id 17. Long before the server had been killed, it had dropped this tablespace and written a FILE_DELETE record, in a CREATE OR REPLACE TABLE operation.

If I start the recovery with a larger buffer pool, it will recover just fine. The changes that were made in MDEV-29911 could possibly be to blame for this.

I am unable to attach a copy of the data directory here, because it would exceed the maximum Jira attachment size. The data set uses encryption, and encrypted data is not compessible.