Rename project to sacredK

sacred_re.dll/.exe/.ini/.log/_crash files are now sacredK.*; inventory saves
with the old "sacred_re.inventory" format id still load.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -6,8 +6,8 @@ project, autotest) first; this file adds how we work and what we learned.
 
 ## What this is
 
-`sacred_re.dll` is injected into the original **Sacred Gold 2.28**
-`sacred.exe` (2006, 32-bit, MSVC 6) by the launcher `sacred_re.exe`. It
+`sacredK.dll` is injected into the original **Sacred Gold 2.28**
+`sacred.exe` (2006, 32-bit, MSVC 6) by the launcher `sacredK.exe`. It
 hooks and patches the running game: some functions are rewritten, most of
 the work so far is **mods** — behaviour changes on top of the original
 (widescreen, HUD layout, 7 weapon sets / art slots, key bindings, WASD,
@@ -15,7 +15,7 @@ auto-attack, skill reworks, respec, map fixes, ...). The game stays playable
 at every step; the user plays it to test.
 
 - Target binary: the original `sacred.exe` in `D:\Gaming\Sacred Gold\`
-  (path in `build\x86-debug\sacred_re.ini`, `[paths] GameDir`). Ignore the
+  (path in `build\x86-debug\sacredK.ini`, `[paths] GameDir`). Ignore the
   `SacredReborn*` files in that folder.
 - Game texts are German (Fertigkeiten, Attribute, Blitzschlag, ...); keep the
   game's names when talking about features.
@@ -65,12 +65,12 @@ at every step; the user plays it to test.
 
 ```powershell
 .\build.ps1                                   # x86-debug -> build\x86-debug\
-build\x86-debug\sacred_re.exe log             # start the game with the DLL
+build\x86-debug\sacredK.exe log             # start the game with the DLL
 ```
 
 New source files must be added to `CMakeLists.txt`. Output to check:
-`build\x86-debug\sacred_re.log` (written anew each start; our lines plus the
-game's own log). Crashes: `sacred_re_crash.txt` / `.dmp` next to the DLL
+`build\x86-debug\sacredK.log` (written anew each start; our lines plus the
+game's own log). Crashes: `sacredK_crash.txt` / `.dmp` next to the DLL
 (exception, module+offset, ebp chain); Windows also records the faulting
 offset in the Application event log (`Get-WinEvent`, provider "Application
 Error"). The debug build's run-time checks turn calling-convention mistakes