Support numeric (atom:Float) LV2 patch properties

[diamondsea11]

Draft — one topic extracted from my fork, as discussed by email. Not build-tested against your CI yet; the TypeScript side type-checks clean (tsc -b --force).

Problem

Lv2PluginInfo::FindWritablePathProperties accepts a patch:writable lv2:Parameter only when its rdfs:range is atom:Path or atom:String. Anything else sets unsupportedPatchProperty = true, which removes the plugin from the plugin list entirely (with the one hard-coded exception for urn:brummer:neuralrack).

Several plugins put ordinary numeric knobs on patch properties instead of control ports — the Dusk Audio series is the case I ran into. They're not "unsupportable" in the sense that JUCE plugins are; they simply have no renderer.

Change

• Accept rdfs:range atom:Float as a supported patch property (an empty branch alongside the existing atom:String one, so it no longer trips unsupportedPatchProperty).
• Lv2PatchPropertyInfo now also reads lv2:minimum, lv2:maximum, lv2:default, the lv2:portProperty flags (logarithmic, integer, enumeration, toggled) and lv2:scalePoint / rdf:value, plus rdfs:label — which was already in the JSON map and in the TypeScript class but was never populated on the C++ side.
• writable, readable and index are added to the JSON map for the same reason: Lv2PatchPropertyInfo.deserialize() in Lv2Plugin.tsx already reads them.
• New PatchPropertyControl.tsx renders one property using the existing PluginControl, driven by Lv2PatchPropertyInfo.toUiControl(). It uses getPatchProperty / setPatchProperty / monitorPatchProperty as they already exist, so there is no protocol change.
• PluginControlView appends the writable numeric properties (in lv2:index order) after the control ports and before the file properties.

Scope notes

• Defaults are conservative: absent lv2:minimum/maximum give a plain 0..1 range, matching what LV2 says about parameters without a stated range.
• Non-writable (read-only) properties are not rendered.
• This deliberately does not touch ModGuiHost. Resolving MOD-GUI mod-port-symbol references to patch properties is a separate topic and a much larger diff; I've kept it out.
• No tests — I didn't see an existing pattern for testing plugin metadata parsing, and I'd rather follow yours than invent one. Happy to add whatever you'd like here.

Let me know if you'd prefer the range/scale-point parsing factored differently, or the rendering to live somewhere other than PluginControlView.