Valid full-resolution screen evidence becomes unavailable during processing

[RolandUI]

During #182 focused validation, LocalBridgeClientTests.FullResolutionScreenPairIsComparedOrRejectsInvalidHalfBeforeDecode(nativeCase: "valid") failed at line 61: expected Rendered.Status=captured, observed unavailable. The controlled IPC fixture supplies matching valid 3840x2160 PNGs; the test took 7 seconds. Exact first evidence is retained in artifacts/agent-qa/expanded-campaign/startup-diagnostics.log and the final TRX for that run. Current source is b90ca39 plus the #182 IPC diagnostic/readiness changes; the screen processing code is unchanged.

CaptureScreenAsync compares the complete frames before saving either, sharing a request.TimeoutMs=5000 processing deadline. CompareScreenFrames uses per-pixel GetPixel calls; if it consumes that budget, Save sees cancellation and drops both already captured frames. The failure message currently hides whether cancellation, decode or filesystem caused Save to fail. The original failed result did not retain that distinction, so comparison budget exhaustion remains a hypothesis until measured/controlled reproduction.

Acceptance:

• Retain the original failure and add bounded stage/reason/timing evidence without image contents.
• Reproduce a comparison deadline or actual failing save cause; preserve already acquired valid evidence when optional comparison cannot complete, with explicit timeout/partial status and bounded caller cancellation.
• Compare every applicable pixel at 3840x2160 in the successful case; preserve dimension/byte/overflow/privacy guards. Do not shrink the tested image or simply raise all timeouts.
• Validate meaningful regression plus native paired captures through CLI/MCP; preserve exact unavailable-platform gaps.

Queued behind the sole active #182, with #172/#173/#174 expansion still unfinished. No release/publication.

[RolandUI]

Starting #183 as the sole implementation issue. Retain the first 7-second valid-4K failure; first expose the already returned comparison/save diagnostics and elapsed time in the existing controlled test, then measure the full-resolution processing path before changing it. Review the optional comparison/save ordering and repeated Skia calls while preserving all pixel, privacy, size and deadline guards. Native paired CLI/MCP validation follows a demonstrated fix. #181/#182/#179 remain in review and full CI 36072375163 must finish without cancellation; #172/#173/#174 expansion remains unfinished.

[RolandUI]

Reproduced on unchanged screen-processing code: screen-before-results/screen-before.trx has 3 passed/1 failed. The valid 3840x2160 case returns after 5151 ms with comparison.status=timeout, comparedPixels=8202240 (of 8294400), and BOTH previously captured frames unavailable/no filePath. This establishes comparison budget exhaustion and subsequent Save cancellation as the loss mechanism in the controlled reproduction; the original first failure lacked these details.

First validate artifact ordering independently: save both frames before optional comparison, keeping the SAME shared processing deadline. Retain safe save-stage/exception/cancellation/timing details. The original comparison test is expected still to expose the slow loop until the next measured optimization; preserve this intermediate result. SkiaSharp 3.119.4 source shows Width/Height query native Info and GetPixel makes a native call each time, while Pixels retrieves all converted SKColor values in one native call: https://github.com/mono/SkiaSharp/blob/f568ac94dd768ef9a2f593537cfde2dd0d348ef5/binding/SkiaSharp/SKBitmap.cs . Prefer the existing public bulk API and cache dimensions; retain full resolution and bounded memory/pixel limits.

[RolandUI]

Validated fix 52f17c0. All 29 full-resolution screen/privacy guards pass (screen-after-results/screen-after.trx, 31 s), including the last pixel, alpha exclusion, exact tolerance boundary and invalid byte/dimension/overflow cases. Valid 4K test duration is 1.875 s including setup versus about 6 s in the failed pre-fix run; comparison still counts all 8294400 opaque pixels under the unchanged 5-second budget. Two public bulk-color arrays add at most 64 MiB under the existing limit.

The ordering-only intermediate run separately demonstrated both files preserved when comparison still timed out at 5290 ms (screen-preserve.trx); the final optimization completes comparison. Safe save-stage/timing/cancellation diagnostics are retained without exception text/image contents.

Actual Windows CLI/MCP paired capture passed 1/1 in 38 s on 52f17c0, with unchanged 47034aa provider and existing standalone screen fixture. Evidence: artifacts/agent-qa/native-screen-183-01/screen/validation.json and expanded-campaign/native-screen-results/native-screen.trx. All five samples are actual win32_desktop_bitblt native captures (400x300, not 4K): clean, red occlusion, green popup, fully masked black, and offscreen transparent regions. Six native/rendered images were visually reviewed. The occluded pair differs at 19989 pixels; privacy comparison is privacy_masked; offscreen comparison excludes absent pixels (57600 compared). The owned fixture process was cleaned up by the completed test. Real native 4K/Retina coverage remains separate and must not be inferred from this Windows run.

Move to review pending combined cross-platform validation. Previous full CI 36072375163 on b90ca39 passes Windows/all native labs but fails independent Linux recovery #184 and macOS gesture #185; #179/#181/#182 remain in review. Resume #172 fixture expansion, then #173/#174 and remaining bugs. No release.