[Android] Fix the HCPP SurfaceControl transaction-list race and split the transaction entry points - #192606

… thread confinement

Consolidates per-frame platform-thread transactions (clips, overlays) into
a single transaction per frame, while isolating raster-thread swapchain buffer
presentations into thread-confined transactions to prevent concurrent mutation crashes.

The existing tests cover the structure of the change (consolidation,
raster isolation, closing dropped transactions) but none of them fail if
the locking is removed. This adds one that does.

The test models the real access pattern: four background threads call
createTransaction() the way the raster thread does once per AHB swapchain
present, while the platform thread calls it twice per round (standing in
for maybeApplyClipToSurfaceView(), once per SurfaceView platform view)
and then runs swapTransactions() and onEndFrame(). Rounds are
barrier-synchronized so the collision density is a property of the test
rather than of how two free-running loops happen to balance on a given
machine.

Measured against the parent of the first commit on this branch, it fails
10/10 runs, every time with the production stack trace:

  java.lang.NullPointerException: Cannot read field "mResizedSurfaces"
      because "other" is null
    at android.view.SurfaceControl$Transaction.merge(SurfaceControl.java:4982)
    at io.flutter.plugin.platform.PlatformViewsController2.onEndFrame(
        PlatformViewsController2.java:673)

On device that NPE unwinds into onEndFrame2(), where
FML_CHECK(fml::jni::CheckException(env)) turns it into an abort().

With the fix it passes 10/10 and costs 56ms.

Some notes on why this is safe to run in CI:

- It is a probabilistic detector, but a one-sided one. It contains no
  timing assertions, so scheduling decides whether it catches an
  unsynchronized implementation, never whether it fails a synchronized
  one. It will catch wholesale loss of the locking; it is not guaranteed
  to catch a subtle partial regression.
- It asserts a floor on completed rounds. A concurrency test that
  silently does no work is worse than no test, because it reports green.
- Joins are bounded and the barrier is broken explicitly during cleanup,
  so a failure reports immediately instead of waiting out a timeout, and
  a hang fails legibly instead of wedging the bot.

The presents-per-round constant is load-bearing: it sets how long
swapTransactions() stays exposed to a concurrent add(). At 8 the
detection rate drops to 8/10, at 64 it is 10/10.

Generated with Gemini assistance.

…te from empty transaction apply

- In onEndFrame(), remove the zero-transaction early return and make
  flutterView.invalidate() unconditional, while guarding
  rootSurfaceControl.applyTransactionOnDraw(tx) on a non-null tx.
  This ensures any pending transactions held in ViewRootImpl are still
  drawn, and re-activates the flutter#190609 regression tests.
- Add a test verifying onEndFrame() invalidates even when zero
  transactions are produced.
- In swapTransactions(), update close() documentation to clarify that it
  releases the acquire-fence FD and native memory rather than recycling
  buffers.
- In createTransaction(), clarify that while transaction lists are
  synchronized, transaction objects themselves still have a pre-existing
  native-side write-after-publish race.
- In the concurrency stress test, separate product-level assertion
  failures from harness-level timeouts/stalls using Assume.assumeNoException
  to prevent false-positive bug reports on loaded CI bots.
- Remove the dead minRounds floor in the stress test and document coverage
  boundaries.

Generated with Gemini assistance.

…ionale

onEndFrame() now always allocates a merge destination, always merges, and
always calls applyTransactionOnDraw(), which is master's control flow. The
only remaining behavioural deltas from master are the lock, the
platform/raster split, and the close() calls.

Skipping the apply on an empty frame saved roughly one allocation on a path
that barely occurs: on API 34+ with a live AHB swapchain there is always at
least one raster transaction, because createTransaction() is called
synchronously inside frame->Submit(). It also weakened the flutter#190609
regression tests by returning before the rootSurfaceControl guard. The
optimization can be argued separately on its own numbers.

Removes onEndFrameInvalidatesEvenWhenTheFrameProducedNoTransactions, whose
never().applyTransactionOnDraw() assertion was that behaviour.

Also corrects the justification for close(). An earlier commit message
claimed it releases buffer references deterministically. It does not: for an
applied transaction the completion callback is registered with libgui's
process-global TransactionCompletedListener, and destroying the Java object
unregisters nothing. What close() does release promptly is the native
transaction and the file descriptors it owns, including acquire fences
merged in from raster buffers. A discarded platform transaction carries only
alpha/crop/visibility, so it has no buffers or fences at all.

Matches the dominant convention in the Android embedding, where list
iteration uses for-each roughly 111 times to 3. The indexed loops that
remain are mostly SparseArray, which has no Iterator.

Review feedback on flutter#192606.

Platform transactions only touch SurfaceControls that the detach
invalidates, including the overlay that destroyOverlaySurface() just
released, and nothing outside the platform thread references them, so
close them. Raster transactions are dropped without closing: their
native producers may still be writing into them.