AUv2: presets are numbered from an unsorted, incomplete crawl

[defiantnerd]

Finding PD-5 from the 0.16 release review. The VST3 side of this was fixed in the preset-selector work; AUv2 has a narrower version of the same problem.

The problem

src/wrapasauv2.cpp:368. rebuildPresetCache() numbers and publishes an incomplete, not-yet-sorted preset list, and the crawl re-sorts when it completes. A preset number the user clicks during that window resolves via presetAt to a different preset than the one whose name they saw.

Narrower than the VST3 case (PD-4) because AU re-reads the list, so it self-corrects — but the root cause is the same: publishing an order before the order is final.

Suggested fix

Publish only a complete crawl, as the VST3 path now does after PD-2/PD-4 — _presetCacheBuilt already tracks isComplete(), so the pieces are mostly there. Alternatively, sort as entries arrive so the order never changes under the host.

Worth checking against the VST3 fix in the preset-knot PR for consistency: both formats should agree on when a list is publishable.

[defiantnerd]

Fixed in #564, merged to next as d48f9c6.

Worth recording that the diagnosis here was off: the isComplete() gate this issue asks for already existed — it arrived with b187f89 (#537), before the issue was filed. The actual defect was that rebuildPresetCache() still filled the cache from the partial list and numbered it, merely flagging the cache unbuilt. Since stable_sort runs only when the crawl finishes, a host reading mid-crawl saw names against numbers that resolve to other presets once the sort lands.

The cache now stays empty until the crawl completes, matching what PD-2/PD-4 (9617822) settled for VST3, so both formats agree on when a list is publishable.