linux, sway, wlr capture fails on Intel due to stride mismatch (Yf-tiled)

Nobody has claimed this yet.

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your issue described in the documentation?

- [x] I have read the documentation

### Is your issue present in the latest beta/pre-release?

_No response_

### Describe the Bug

## Environment
- **OS**: Debian testing
- **Compositor**: Sway 1.12 (wlroots 0.20)
- **GPU**: Intel Kaby Lake (HD 620) - Surface Pro 5
- **Driver**: intel-media-va-driver 26.1.6 (iHD)
- **Sunshine version**: 2026.826.1804 (commit f273ce8f45db0bd6c7810a0f2c77e170f1a40f6e)
- **Display**: Physical screen, eDP-1, 2736x1824

## Problem
Sunshine fails to capture screen via wlr-screencopy protocol with repeated `[wayland] Frame capture failed` errors. The compositor consistently rejects the screencopy request with `zwlr_screencopy_frame_v1.failed()`.

KMS capture works fine. Other tools using the same protocol (grim, wl-screenrec) work successfully on the same system.

## Root cause (from Wayland protocol trace)
Stride mismatch between what the compositor advertises and what Sunshine allocates:

```
Compositor advertises:
zwlr_screencopy_frame_v1.buffer(875709016, 2736, 1824, 10944)
^^^^^^^^^ XR24 format ^^^^^ stride

Sunshine allocates:
zwp_linux_buffer_params_v1.add(fd, 0, 0, 11008, 16777216, 4)
^^^^^ stride (should be 10944)
^^^^^^^^^^^^^^^^^ modifier: Intel Yf-tiled

Compositor response:
zwlr_screencopy_frame_v1.failed()
```

Sunshine calculates stride as 11008 (64 bytes more than required), while the compositor expects exactly 10944 bytes (2736 pixels × 4 bytes/pixel). With Intel Yf-tiled modifier, wlroots strictly enforces stride alignment and rejects the mismatch.

## Expected behavior
Sunshine should use the stride value provided by the compositor in the `.buffer()` event, not calculate its own.

## Verification
Tools that work correctly (wl-screenrec) use stride 10944 in their `.add()` call, matching the compositor's `.buffer()` event.

## Workaround
Setting `capture = kms` in sunshine.conf works as a temporary solution.

## Full protocol trace excerpt

Click to expand

```
[ 298465.311] {Default Queue} zwlr_screencopy_frame_v1#8.buffer(875709016, 2736, 1824, 10944)
[ 298465.319] {Default Queue} zwlr_screencopy_frame_v1#8.linux_dmabuf(875713112, 2736, 1824)
[ 298465.323] {Default Queue} zwlr_screencopy_frame_v1#8.buffer_done()
[ 298473.915] {Default Queue} -> zwp_linux_dmabuf_v1#4.create_params(new id zwp_linux_buffer_params_v1#9)
[ 298473.933] {Default Queue} -> zwp_linux_buffer_params_v1#9.add(fd 57, 0, 0, 11008, 16777216, 4)
[ 298473.938] {Default Queue} -> zwp_linux_buffer_params_v1#9.create(2736, 1824, 875713112, 0)
[ 298474.033] {Default Queue} zwp_linux_buffer_params_v1#9.created(new id wl_buffer#4278190080)
[ 298474.042] {Default Queue} -> zwp_linux_buffer_params_v1#9.destroy()
[ 298474.045] {Default Queue} -> zwlr_screencopy_frame_v1#8.copy(wl_buffer#4278190080)
[ 298486.899] {Default Queue} zwlr_screencopy_frame_v1#8.failed()
```

This pattern repeats consistently on every capture attempt.

### Expected Behavior

_No response_

### Additional Context

_No response_

### Host Operating System

Linux

### Operating System Version

debian testing

### Architecture

amd64/x86_64

### Package

Linux - deb

### GPU Type

Intel

### GPU Model

Kaby Lake (HD 620)

### GPU Driver/Mesa Version

intel-media-va-driver 26.1.6

### Capture Method

wlroots (FreeBSD/Linux)

### Apps

```json

```

### Log output

```shell

```

### Online logs

_No response_

Use the supplied Wayland protocol trace as the starting point and trace the wlroots capture path that handles the compositor's .buffer() event and constructs the linux-dmabuf add call. Compare the advertised 10944 stride with the allocated 11008 stride, then verify on the reported Intel/Sway setup that wlr capture succeeds without repeated frame-capture failures.

Written by the indexing model from the issue text.