Test coverage is far below target -- tracking issue for expansion toward 85% #5

Summary

Upstream chromiumembedded/java-cef (and this fork, prior to #2) has thin test coverage on both sides of the JNI boundary, and no CI running it:

• Java: 131 classes under java/org/cef/, only 5 JUnit test classes in java/tests/junittests/ (DisplayHandlerTest, DragDataTest, TestFrameTest, plus OsrSmokeTest/ModifiedUtf8Test added in Fix modified-UTF-8 corruption in JNI string marshaling #1/Add CI (Azure Pipelines + CodeQL) with build/test/coverage, and test-bench fixes needed to get there #2). Covers a handful of code paths -- title/address change, CefDragData getters/setters, one browser lifecycle, JNI string encoding. No coverage for CefApp's state machine, CefClient, CefCookieManager, most of CefRequest/CefResponse, CefMenuModel, CefPrintSettings, or the network/callback/misc packages.
• Native/C++: 146 source files under native/, zero test framework wired into the build at all (no gtest, no CTest -- grepped CMakeLists.txt, nothing). Native code is only exercised indirectly through whatever a JUnit browser test happens to touch.
• CI: none prior to Add CI (Azure Pipelines + CodeQL) with build/test/coverage, and test-bench fixes needed to get there #2 -- .github/workflows/ had only issue templates.

Target

Project requirement for the planned Panama/Silk JNI-boundary migration: 85% coverage, covering both happy and unhappy (error) paths, before that work begins in earnest. Rough sizing estimate given the surface area (131 Java classes, 146 native files): likely somewhere in the 800-1200 test range to hit that bar with meaningful branch coverage, not just line coverage.

Reference: JetBrains/jcef

JetBrains/jcef (shipped in JetBrainsRuntime/IntelliJ) has a substantially larger JUnit suite (~13 test classes vs our 5) including scenarios we have zero coverage for -- CefMessageRouter JS-query round-trips (HandleJSQueryTest), repeated browser create/dispose cycling (MultipleBrowserCreationTest), keyboard/mouse simulation, SSL. Not directly portable (built on their JBCefBrowser/CefLog wrapper classes, which don't exist upstream, and windowed-mode tests that would hit #3), but valuable as a source of test scenarios to reimplement against our own TestFrame+OSR pattern. Suggested priority: message-router round-trip and repeated-create/dispose cycling first, since those are currently completely uncovered.

Not in scope for this issue

This is a tracking/planning issue, not asking for all ~800-1200 tests in one PR. Use it to link sub-issues/PRs as coverage work lands.