JCEF has no CefFindHandler binding (no onFindResult) -- find()/stopFinding() are fire-and-forget #32

Summary

org.cef.browser.CefBrowser.find()/stopFinding() exist (wired to native/CefBrowser_N.cpp), but there is no Java equivalent of CEF's CefFindHandler/OnFindResult -- no way for a Java caller to observe when an in-page find operation actually completes. grep-confirmed: no find_handler.cpp/FindHandler anywhere in native/ or java/org/cef/handler/.

CEF's own CefFindHandler::OnFindResult (include/capi/cef_find_handler_capi.h) is the intended way to know a find request settled; ~/devel/cef/tests/ceftests/find_handler_unittest.cc always waits for OnFindResult's finalUpdate before calling StopFinding().

Impact

Without this binding, find() is fire-and-forget from Java: a caller has no way to know when it's safe to act on the result, or safe to close/tear down the browser without a find request's mojo IPC still being in flight. Found via #27: a browser force-closed shortly after find()/viewSource() can hit a Debug/coverage-build-only DCHECK (interface_endpoint_client.cc:538: !has_pending_responders()) in CEF's own mojo layer, because nothing ever drains the pending response. Current test-level mitigation (CefBrowserApiTest.java) is a settle delay before closing, which is not a real fix, just a workaround for this gap.

Suggested fix

Add native/find_handler.cpp + org.cef.handler.CefFindHandler (onFindResult(CefBrowser browser, int identifier, int count, Rectangle selectionRect, int activeMatchOrdinal, boolean finalUpdate)), wired into client_handler.cpp/CefClient the same way every other handler type is (see CefJSDialogHandler/jsdialog_handler.cpp for the smallest comparable pattern to follow).