SD-loaded mnemonic awaiting confirmation is not cleared on session lock

[kkdao]

Checked on master 5ef4db5.

scan_load_content() does not register scan_page_destroy() with session cleanup, unlike scan_page_create(). The SD load page registers its own destructor, but that only destroys the file browser.

Consequently, loading a mnemonic through Home → Load and leaving “Replace current key?” unanswered until inactivity lock leaves scan_ctx.scanned_mnemonic allocated. The lock clears the screen and active wallet, but does not wipe this pending mnemonic.

Reproduction: start a fresh session, load a wallet, open a different mnemonic from SD, and let the confirmation screen time out.

Expected: session lock wipes and releases the pending mnemonic and clears the scan context.

This is separate from #184: that concerns key_confirmation.c; this concerns the SD entry into scan.c. Verified by tracing the current code; hardware reproduction remains pending.

Additional validation: a focused host test using the actual SD-load, mnemonic-handler, session-cleanup and lock functions reproduced the pending mnemonic remaining intact after lock. Adding cleanup registration in scan_load_content() made the test pass. UI and cryptographic dependencies were stubbed; this was not a full simulator or physical-device test.

[odudex]

Confirmed, and the scope is wider than the pending mnemonic. When scan_load_content() is the entry point, nothing that scan_page_destroy() owns gets cleaned up at session lock: the parsed PSBT, the sankey diagram, the export menu, the descriptor-loader and address-checker state, and the deferred timer. lv_obj_clean() also leaves scan_ctx.screen dangling. The gap dates from 4dc6448, which added the cleanup registration to scan_page_create() but missed the SD entry point.

Fix: register first thing, the same way scan_page_create() does:

 void scan_load_content(lv_obj_t *parent, const uint8_t *data, size_t len,
                        const char *save_dir, const char *source_name,
                        void (*return_cb)(void), void (*complete_cb)(void)) {
+  session_cleanup_register(scan_page_destroy);
   if (!parent || !data || len == 0)
     return;

The ordering is safe. load_page_destroy is registered earlier, so lock tears down scan first and then the file browser. load_finished_cb and load_complete_cb already call scan_page_destroy(), which unregisters itself, so normal exits stay balanced.