[kalpakprod]

What changed

Runtime::invoke_import_cached caches the resolved HLE function per import slot in import_bindings_. A slot is a per-corpus ordinal, so two corpora (a main executable plus a PRX module, both with their own import tables) use the same slot numbers for different imports. The cache did not check which import it had been filled for, so the first corpus to touch slot N decided what every later corpus got for slot N.

Each cached binding now stores the (library, nid) it was resolved for and is reused only for that pair; otherwise the import is resolved again and the slot is overwritten.

Why

Found while bringing up a game with a main executable and 31 PRX modules loaded at run time. A module's sceKernelCreateThread import (slot 60) hit the main executable's cached slot 60, a different ThreadMan function. The module's main thread was never created, the game stopped at a black screen, and other cross-corpus slots misdispatched into blocking calls (frames of 400 to 600 ms with the guest idle). With the change the same game gets past module start, shows its menu and plays its intro movie.

How it was verified

• This branch: g++ -std=c++20 -fsyntax-only src/runtime.cpp is clean.
• The identical change was applied to the framework clone of a game port, one translation unit rebuilt and relinked, and a 45 s run on Linux with rendering and audio: the module's main thread started, interpreter fallbacks stayed at zero, no [hle-stub] lines.

Not verified

• ctest and the CI platforms (macOS, Windows) were not run on this branch.
• Single-corpus programs are unaffected by construction (one corpus, no slot reuse), but I did not measure their dispatch time. The check adds one integer compare and, on equal NIDs, one string compare per cached import call; if that matters on the hot path, comparing an interned library id instead is a small follow-up.