Fix FlutterActivityTest logcat marker priority and narrow graphics error filtering - #195707

Related to #191348
Related to #193557
Related to #193205
Related to #195708

What changed

I fixed a log-level filtering bug in FlutterActivityTest.kt's getGraphicsPipelineErrors and extracted explicit fatal graphics error matching into GraphicsErrorLogFilter.kt inside dev/integration_tests/android_hardware_smoke_test.

Previously, templateTest logged its attempt boundary marker via Log.i(TAG, marker) (INFO priority), whereas getGraphicsPipelineErrors queried logcat -d --pid=$pid *:W (WARN and above). Because *:W stripped all INFO lines from the dump, seenMarker never flipped to true and process-level EGL or Vulkan errors went undetected during instrumented runs. At the same time, matching any post-marker line containing "HWUI" or "EGL_" matched benign warnings emitted unconditionally by Android's HWUI RenderThread on emulators (Failed to choose config with EGL_SWAP_BEHAVIOR_PRESERVED, 101010-2 ... error = EGL_SUCCESS, Unknown dataspace 0, and slow-frame HWUI: Davey! logs), which would immediately preempt BlankScreenshotException retries once marker detection armed.

getGraphicsPipelineErrors now passes logcat -d --pid=$pid $TAG:I *:W so the Log.i boundary marker remains visible in the dump, and GraphicsErrorLogFilter matches explicit unrecoverable EGL, Vulkan, and emulator host-pipe errors while excluding 'EGL_SWAP_BEHAVIOR_PRESERVED' and 'error = EGL_SUCCESS' specifically (preserving real libEGL eglInitialize(...) failed (EGL_SUCCESS) disconnect detection).

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 in-code documentation (doc comments with ///).
• If this PR introduces a new feature or capability, I created and linked a website documentation issue or PR in flutter/website (or verified none is needed).
• 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.