WebView: drop setEditableFocusActive + responder-chain forwarding

[jakepenn]

Summary

Consumers (minimal_core) have switched to a JS-side keyboard triage that routes host-bound keys through a custom bridge call on both platforms, so the JUCE-side editableFocusActive + WKWebView responder-chain forwarding patch is no longer driving anything.

Removed:

• WebBrowserComponent::setEditableFocusActive public API
• Platform::setEditableFocusActive virtual + Windows/macOS overrides
• Auto-registered __juceSetEditableFocusActive native function
• macOS WKWebView keyDown:/keyUp: overrides that forwarded to next responder
• editableFocusActiveMemberName ivar plumbing and helper accessors
• The editableFocusActive check inside the macOS performKeyEquivalent: override (the original JUCE Cmd-X/C/V/A clipboard handling stays)

Net result is reverting the macOS half of #26 (WebView: forward keys to host responder chain by default), the API + native-function plumbing it added in WebBrowserComponent.{h,cpp}, and the corresponding mac.mm changes. macOS now behaves like upstream JUCE for keyboard events — WKWebView dispatches to the DOM, the embedded JS does the triage, and the consumer-side bridge handles host forwarding via a synthesised NSEvent that bypasses WKWebView.

Test plan

• Plugin in DAW (macOS): typing into preset search works; Space transport reaches the DAW via the new JS triage path; Cmd-X/C/V/A still work in DOM inputs (JUCE's original performKeyEquivalent: clipboard handling)
• Plugin in DAW (Windows): same as before (existing Windows path unaffected)
• Standalone Windows / macOS: no regressions

🤖 Generated with Claude Code

[jakepenn]

Reverting: keeping the WKWebView responder-chain forwarding + setEditableFocusActive API on macOS. The consumer-side symmetric approach this was paired with introduces a static keyCode translation gap on Mac that's strictly worse than the responder-chain forwarding's transparent passthrough.