test_prepare_hs03 simulates a crash by copying the database directory to RESTART and reopening the connection there, then calls corrupt_salvage_verify() one last time to exercise salvage after a crash.

That last corruption does not reach the reopened database. setUpConnectionOpen records the new home in self.home but does not change the process working directory, while corrupt_table builds a relative file name from the test name. The relative name resolves against the original directory, so the corruption overwrites the pre-restart file the test has already finished with.

Confirmed by printing the absolute path each corruption targets, with the connection's home, for corrupt_table.string-row:

CORRUPTING .../WT_TEST/test_prepare_hs03.0/test_prepare_hs03.wt   conn home= .
CORRUPTING .../WT_TEST/test_prepare_hs03.0/test_prepare_hs03.wt   conn home= .
CORRUPTING .../WT_TEST/test_prepare_hs03.0/test_prepare_hs03.wt   conn home= RESTART

The third call is made with the connection on RESTART but writes to the file in the parent directory. The final salvage therefore runs against an intact table and the post-crash corruption path is not tested.

checkpoint_extent_list_blocks in the same function reads the extent-list offsets to protect from the RESTART session, so those offsets are being applied to a different file as well.

Fixing this means the final salvage would operate on a genuinely corrupted post-crash database for the first time, so it may expose failures rather than simply passing. That is why it is filed separately rather than corrected in place; a FIXME in the test refers here.