VST3: two more loops assume isMidi is the only non-CLAP parameter

[defiantnerd]

Found while fixing VST3-2 in the 0.16 release review, which fixed the same assumption in the CLAP_PARAM_RESCAN_INFO loop.

The problem

The preset selector created by Vst3Parameter::createPresetSelector is not a CLAP parameter: it has an invented ParamID and leaves param_index_for_clap_get_info at 0. VST3-2 fixed one loop that skipped only p->isMidi and therefore fed the selector's id to CLAP. Two more do the same:

• syncParameterValuesFromClap() (src/wrapasvst3.cpp ~:369) calls get_value with the selector's invented id.
• getParamValueByString() (~:695) skips only isMidi, so text_to_value is called with it too.

Both are harmless today, but only because the plugin rejects an unknown id and the wrapper treats the failure as "no value" / kResultFalse. That is relying on every plugin implementing those calls defensively, which is not something the wrapper should depend on.

getParamStringByValue is already correct — it tests kIsProgramChange first.

Suggested fix

Skip p->isPreset alongside p->isMidi in both, matching the VST3-2 fix. Longer term, a single predicate (isWrapperOwned(), say) used by every loop that walks parameters would stop the next special-case parameter from re-introducing this.

[defiantnerd]

Fixed in #562, merged to next as d92dc5f.

Rather than patching the two loops named here, Vst3Parameter::isWrapperOwned() (isMidi || isPreset) now covers every walk of the parameter container, including the two that were already correct — a grep for isMidi in wrapasvst3.cpp returns nothing.

One place the predicate deliberately does not apply: detail/vst3/process.cpp:297,314 dispatches on isPreset and isMidi separately and in that order, and that split is load-bearing — the selector must not become a 0xC0 message. A future wrapper-owned parameter kind still needs its own branch there.

Verified: build gate plus the full CI matrix.