[🐛 Bug]: LogTest.testRetrieveStacktraceForALog fails deterministically since 2026-09-09 (expected 4 stack frames, got 3) #2833

What happened?

dev.selenium.bidirectional.webdriver_bidi.LogTest.testRetrieveStacktraceForALog in examples/java has been failing deterministically on every CI run (scheduled nightly java-examples.yml, and any PR that touches examples/java/**) since 2026-09-09. Last known good scheduled run: 2026-09-08. First failing scheduled run: 2026-09-09. It reproduces on ubuntu, windows, and macos, on both stable and nightly Chrome, so it isn't flaky/timing-related — every attempt (including Surefire's built-in reruns) fails the same way:

dev.selenium.bidirectional.webdriver_bidi.LogTest.testRetrieveStacktraceForALog:100
expected: <4> but was: <3>

The test clicks #logWithStacktrace on https://www.selenium.dev/selenium/web/bidi/logEntryAdded.html, whose handler chain is:

<button id="logWithStacktrace" onclick="bar()">...</button>
<script>
  function foo() { throw new Error('Not working'); }
  function bar() { foo(); }
</script>

and asserts the resulting StackTrace has exactly 4 call frames. It's now consistently returning 3. This looks like a change in how the inline onclick attribute handler frame is represented in the stack trace (browser or BiDi log-entry reporting change) rather than anything wrong with the example/test page itself, but I haven't traced the exact upstream cause.

Noticed while investigating unrelated CI failures on PR #2831; the test isn't touched by that PR and the failure is pre-existing on trunk.

What browsers and operating systems are you seeing the problem on?

Chrome (both stable and nightly channels), reproduced on ubuntu-latest, windows-latest, and macos-latest GitHub Actions runners.