Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7.
- [Release notes](https://github.com/actions/checkout/releases)
- [Commits](actions/checkout@v6...v7)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-version: '7'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

…actions/checkout-7

chore(deps): bump actions/checkout from 6 to 7

…anthropics/claude-code-action-1.0.162

chore(deps): bump anthropics/claude-code-action from 1.0.157 to 1.0.162

RenderTargetBitmap now records the visual tree into an SKPicture on
the UI thread (mirroring the regular rendering pipeline) and replays
it into a GRContext-backed surface during the CompositionTarget's next
render pass, reading the pixels back into the caller's buffer. The
GRContext is resolved from the draw canvas (SKCanvas.Context), so the
mechanism is platform-neutral and applies to every Skia backend; when
the target renders in software (raster canvas), pending render jobs
fail fast and the previous raster path is used as fallback.

Opting out is possible via the new
FeatureConfiguration.Rendering.UseGpuRenderTargetBitmap flag, since
GPU rasterization can produce slightly different anti-aliasing than
the software rasterizer.

RenderAsync now completes asynchronously on Skia (one render pass
later) instead of synchronously inside the call.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Adds an orientation test guarding against vertically-flipped output on
GPU backends with bottom-left-origin surfaces, and pins
When_CornerRadius_AntiAliasing to software RenderTargetBitmap since
its reference asset was rendered by the software rasterizer and GPU
anti-aliasing differs slightly along the rounded edge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

GPU rendering of RenderTargetBitmap is now always on when the target
renders with a GRContext. When_CornerRadius_AntiAliasing consequently
can no longer pin itself to the software rasterizer, and no RMSE
threshold separates valid GPU-vs-CPU anti-aliasing variance (0.0325)
from a simulated non-anti-aliased render (0.0349) on this image, so
the test now asserts the invariant directly: a meaningful fraction of
the pixels in a ring around the circle's edge must blend between the
two colors (~34% for the CPU rasterizer, 0% for a jagged render). Its
software-rendered reference asset is removed with it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Both overloads carried identical copy-pasted bodies differing only in
scaledSize and, through historical drift, in the fallback used when
element is null (PublicRootVisual vs RootElement). They now share one
core, unified on RootElement: the window's root visual, i.e. what is
presented on screen including popups.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The hardware and software paths shared no code despite doing the same
thing: both now record the SKPicture through one method (owning the
layout-clip removal and the IsSoftwareRenderer record-time flag) and
replay it through one method (surface, optional resampling, pixel
read-back). The only difference between the two paths is the surface
factory: GRContext-backed for hardware, raster for the fallback.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Runner images picked up a Homebrew version that refuses formulas from
third-party taps until explicitly trusted, breaking every iOS UI test
stage overnight:

  Error: Refusing to load formula facebook/fb/idb-companion from
  untrusted tap facebook/fb.

Trust only the idb-companion formula (least privilege), with tap-level
trust as fallback and a no-op on older brews that have no trust command.
Also document what this script does and where idb comes from
(sha256-pinned facebook/idb v1.1.8 artifact; tap dormant since 2022).

…ook-tap

ci(ios): trust the facebook/fb tap formula required by newer Homebrew

The drag visual was captured with RenderAsync, which now completes
during a later render pass; the resulting dispatcher yield broke the
synchronous DragStarting -> DragStarted -> DragEnter/DragOver sequence
(matching WinUI) that the drag-and-drop runtime tests assert, failing
them on all Skia CI targets. The capture now uses a synchronous
software render (its behavior before the GPU path was introduced),
while the public RenderAsync stays asynchronous.

Also hardens RenderAsync against overlapping calls on the same
instance: calls are serialized with an async gate and the pending GPU
replay roots the pixel buffer it writes to, so a concurrent
EnsureBuffer can neither resize nor free it mid-write.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

RunRenderJobs took the canvas only to reach its GRContext; callers now
resolve the context themselves. Also asserts UI-thread access in
TryExecuteOnNextRenderAsync, matching the rest of the scheduling
surface.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…ync/feature/breakingchanges

# Conflicts:
#	build/test-scripts/ios-uitest-run.sh
#	src/Uno.UI/UI/Xaml/Media/Imaging/RenderTargetBitmap.cs