0.16 review: four crash-class fixes (PD-1, PD-3, PD-7, SA-1)

[defiantnerd]

First of four batches from the 0.16 release review of main...next. These are the crash-class findings — the ones that take the host down or hang a scan. They are independent of each other and of the rest of the review.

What is here

PD-1 — Windows path encoding could kill the host. fs::path and the CLAP ABI disagree about what a string is. path::string() throws std::system_error for any filename the ANSI code page cannot express, and the crawl runs on a bare std::thread, so one パッド.preset in a user folder was std::terminate for the host. In the other direction fs::path{std::string} decoded a UTF-8 location as ACP, so a plugin declaring a path with a non-ASCII segment had that location silently skipped. Conversions now go through pathFromUtf8() and u8string(), as fsutil.cpp already did everywhere, and the thread body catches everything.

PD-3 — the crawl thread outlived the hosted CLAP. PresetIndex::resetCache() had no callers, and the ModuleTerminator deleted the library — deinit() and unmap — while the crawl was inside provider->get_metadata() in that module. Reaper's in-process rescan either tears the plugin's globals down under a running crawl, or joins it later from a static destructor under DLL_PROCESS_DETACH, where the loader lock stops the thread exiting and the scan hangs. Clearing the cache map alone was not enough, since a live wrapper's shared_ptr keeps its thread alive.

PD-7 — a listener could run on a destroyed wrapper. finish() copied the listener list, dropped the lock, then called the copies — and a copy cannot be recalled, so a destructor that removed its listener could still be called on freed memory. Logic and auval dispose an AU about 100 ms after instantiating it, squarely inside a folder crawl.

SA-1 — macOS quit crashed. applicationWillTerminate: held a shared_ptr copy of the plugin past mainFinish(), so it was the last owner and ~Plugin ran destroy() on an already-deinited entry. Windows already released before mainFinish (there is a comment about it in the WM_DESTROY handler); the macOS path was missed when that landed.

Verification, and its limits

• VST3 target builds clean under C++17; clap-wrapper-shared-detail builds clean under C++20, which is the configuration that matters for the u8string() changes. clang-format clean.
• SA-1 was not compiled. It is macOS-only and was developed on Windows. It is a pure block-scoping change introducing no new API, and the ordering was checked by reading mainFinish in entry.cpp and ~Plugin in clap_proxy.cpp — but it needs a real macOS build before it is trusted.
• There are no tests covering PresetIndex, so the preset fixes are compile-and-reasoning, not runtime proof.

Deliberately left alone

A listener registered in the exact window where a crawl completes can still be called twice. That predates this change and both current consumers only set an idempotent atomic flag.

Note on fs::u8path

Not used, although it is the textbook C++17 idiom: it is deprecated in C++20 and this project builds with -Werror. u8string() is safe here because shared_prologue.cmake turns char8_t off whenever the standard is >= 20, so it returns std::string on every configuration this project builds.