This PR adds native Android instrumented tests to the android_hardware_smoke_test CI suite in parallel to existing driver tests (Part of #187538).

Adds two new shards temporarily, both with bringup: true:

• android_hardware_smoke_vulkan_instrumented_tests
• android_hardware_smoke_opengles_instrumented_tests

These shards run the driver tests first, similar to existing shards, then subsequently run the instrumented tests. They do this via a new optional runInstrumented param in run_android_hardware_smoke_tests.dart.

We'll remove the parameter and put this behavior in the existing shards after it proves stable.

Why do we need to run the instrumented tests sequentially after the driver tests?

I generally prefer to avoid doing multiple things sequentially in an integration test. It tends to introduce flakiness. So for this suite, why can't we have one shard for driver tests and a separate one for instrumented tests?

The driver tests use a skia gold comparator to compare result images to skia gold at runtime. However, no such comparator is available for instrumented tests. goldctl isn't designed to run on android. So we need to get the goldens somehow at APK build time.

In this PR, the integration tests run in two sequential passes. We first execute a host-driven driver test to save reference screenshots, and then run native JUnit tests to compare against those local files. This is the same way we will generate instrumented test APKs to be delivered to OEMs. I considered optimizing this by downloading the latest approved goldens directly from the Skia Gold server. It turns out it's possible to calculate the public URLs based on the test name and some other parameters. So we could theoretically write a script which cheaply fetches all the goldens for the suite. Then we could configure a shard which runs that script instead of the driver tests, achieving an independent shard for instrumented tests only.

However, this downloader approach is incompatible with presubmit. Any PR that introduces a change to the goldens would fail because the script would only return the latest approved goldens. Even after a developer approved the change on the dashboard, subsequent presubmit runs would still download the old goldens, deadlocking the PR checks. Technically that's not a problem for post-submit runs, but I'd rather keep presubmit and postsubmit identical instead of optimizing only postsubmit with something like this.

Running the driver pass first, as we do in this PR, avoids the problem by dynamically capturing reference screenshots generated by the PR's own code. This keeps the skew at zero and allows tests to pass once approved.

Also, I'm not that comfortable relying on calculating URLs, since there would be no guarantee that the URL scheme will remain stable. The URL scheme hasn't changed since 2020, but compared to relying only on goldctl, it just feels more fragile to me. That being said, I've implemented the download script in a personal agent skill instead, where I can use it at my own risk, and it isn't weight bearing in any way.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.