Fix flaky ink_sparkle shader load on master channel

[passsy]

CI on main is red on test_channel (master) (and nightly), failing intermittently with:

Exception: Asset 'shaders/ink_sparkle.frag' not found

Root cause

Widget tests run as TargetPlatform.android, so Material uses the InkSparkle ink splash. The first tap on a Material widget triggers _InkSparkleFactory.initializeShader(), which loads shaders/ink_sparkle.frag via a fire-and-forget Future with no error handler:

ui.FragmentProgram.fromAsset('shaders/ink_sparkle.frag').then((p) => _program = p);
// no .catchError — a rejection becomes an unhandled async error

On the master channel the flutter test asset server intermittently fails to serve that shader when several test processes request assets at the same time. The rejected future becomes an unhandled exception that fails whichever test is running — so it looks flaky (a different test each run, usually a filter_test / timeline tap or drag test).

This is a recent regression in flutter_tools: flutter/flutter#186902 ("unify asset processing", May 27 2026) reworked devfs.dart (the asset-serving layer). It's a recurrence of the class of flutter/flutter#104084. stable, beta and the pinned 3.10 job are unaffected.

Measured against master (3.45.0-1.0.pre): default/-j 2 → 1–2 failures per run; the asset server can't serve even two concurrent FragmentProgram.fromAsset requests.

Fix

flutter test runs every test file in its own OS process (verified: 47 files → 47 PIDs). A test/flutter_test_config.dart pre-warms the shader behind a shared exclusive file lock, so the load is serialized across all test processes. The asset server serves it reliably one request at a time, and FragmentProgram.fromAsset caches the result, so the later InkSparkle load reuses the cached program. Only the (fast) shader load is serialized — tests still run concurrently.

No platform or theme changes, so test behavior is unchanged. Verified locally on master: 5/5 full runs green (394 tests, ~25s each, still concurrent), and green on stable.

Alternatives rejected

• Reduce test concurrency — works but a blunt slowdown that hides rather than fixes the issue.
• Override the platform to avoid InkSparkle — debugDefaultTargetPlatformOverride must be null at each test body's end (debugAssertAllFoundationVarsUnset), and package:test tearDown runs after that invariant check, so a global override is impossible.
• Mock the shader asset — FragmentProgram/ImmutableBuffer.fromAsset are @Native engine calls, not routed through rootBundle, so they can't be mocked from Dart.

[passsy]

Closing: the file-lock pre-warm does not actually fix this. Investigation showed the failure is a probabilistic devfs corruption at concurrent process startup (flutter/flutter#186902), which no in-process pre-warm can repair. See follow-up analysis.