Fix .bat build script. Cleanup .dll.hotreload.live.N binaries on startup.

source/examples/HotReloadLiveDemo/Host/Main.cpp

@@ -95,6 +95,10 @@ int main(int argc, char** argv)
 	std::printf("            (or run watch.sh, in this example's own directory, in another\n");
 	std::printf("             terminal to rebuild automatically every time you save)\n");
 	std::printf(" Stop:      Ctrl+C\n");
+	std::printf(" Note:      rebuild the PLUGIN target above, not \"Rebuild Solution\"/a full\n");
+	std::printf("            clean -- that also tries to delete this Host's own .exe, which\n");
+	std::printf("            Windows refuses to do while it's running (see this example's\n");
+	std::printf("            own README for why that's expected, not a bug)\n");
 	std::printf("================================================================\n\n");
 
 	std::signal(SIGINT, &handleSigint);

source/examples/HotReloadLiveDemo/README.md

@@ -73,9 +73,51 @@ HotReloadContext.cpp`) copies a plugin to a fresh, uniquely-named file
 before ever calling `LoadLibrary`/`dlopen` on it -- built originally to
 sidestep a dlopen caching gotcha on POSIX (see that function's
 comment) -- so the path this example's build actually writes to is
-never the one Windows locks. This reasoning was not verified against
-a real Windows rebuild-while-running cycle specifically (unlike the
-rest of this library's Windows behavior, which was exercised under
-Wine -- see `source/HotReload/README.md`'s verification notes); if a
-rebuild on Windows still fails while the Host is running, that
-mismatch between reasoning and reality is worth reporting.
+never the one Windows locks. Confirmed directly on real Windows/MSVC:
+rebuilding `hotreload_live_plugin` repeatedly while the Host stayed
+running worked correctly, hot-reloading each time.
+
+## "Rebuild Solution" (or any other full clean) fails while the Host is running -- this is expected
+
+Different from the DLL case just above, and this one genuinely can't
+be worked around the same way. Visual Studio's "Rebuild" (and the
+equivalent `cmake --build --clean-first`, or deleting the build
+directory yourself) deletes *every* build output first, including
+`hotreload_live_demo_host.exe` itself -- and Windows will not let you
+delete a running process's own executable image, full stop, for as
+long as it's running. There's no staging trick that helps here the way
+there is for the plugin DLL: the thing being deleted is quite literally
+the file currently executing.
+
+Confirmed directly: this fails with `ninja: error: remove(bin/
+examples/hotreload_live_demo_host.exe): Access is denied.`, and the
+"Rebuild failed" it's reported as makes it look worse than it is --
+depending on your build tool, the *subsequent* build step can still
+run and still correctly rebuild+reload the plugin regardless (also
+confirmed directly), since only the clean step, not the whole
+operation, actually failed.
+
+**The fix is simply not to use "Rebuild"/a full clean while the Host
+is running** -- an ordinary incremental "Build", or building just
+`hotreload_live_plugin` specifically (exactly what `watch.sh` and the
+manual `cmake --build ... --target hotreload_live_plugin` command
+above already do), never touches the Host's own executable at all, so
+neither is affected by this. Stop the Host first if you ever do want a
+genuine full clean.
+
+## Leftover `hotreload_live_plugin.dll.hotreload.live.N` files
+
+Each reload stages the plugin through a fresh, uniquely-named copy
+before loading it (`HotReloadContext::stagePathForLoad()`, needed for
+reasons unrelated to this -- see that function's comment). On Linux/
+macOS, the copy is deleted right after loading and nothing
+accumulates. On Windows, that deletion fails for as long as the module
+it backs stays loaded -- which, by this library's design, is for the
+rest of the Host process's lifetime, so **one leftover file per reload
+during a long editing session is expected**, not a leak to chase down.
+`hot_reload_load()` sweeps up whatever a *previous* run of the same
+Host left behind the next time it starts, so restarting the Host is
+enough to clean up between sessions; within a single very long
+session, some accumulation is simply the cost of every old version
+staying safely addressable. Safe to delete by hand at any point the
+Host isn't running, if it bothers you before then.