fix(windows): handle window resize during WGC capture (frame-pool + encoder + mux coordination)

[coderabbitai]

Follow-up to #422

Requested by: @yusefren

Background

PR #422 fixes window-target capture at startup and normalizes initial frame dimensions to even values. However, if the captured window is resized during an active recording session, the following components all remain fixed-size:

• Direct3D11CaptureFramePool – allocated with initial SizeInt32 at session start
• MF encoder (mf_encoder.cpp) – staging texture, NV12 buffer, and output media type initialized from width_ / height_ in initialize()
• MP4 sink writer – H.264 streams do not support mid-stream frame geometry changes without restarting the file or splicing streams

A complete fix needs to coordinate:

1. Detecting size change via frame.ContentSize() in onFrameArrived
2. Re-applying the even-dimension normalization (round to even, clamp to min 2)
3. Calling framePool_.Recreate() with the new dimensions
4. Rebuilding the MF encoder (new staging texture + NV12 buffer + output media type)
5. Handling the mux layer (e.g., restarting the sink writer segment or opening a new file)

Current behavior

Resizing a captured window during recording produces CopyResource failures (silently producing black output) or clipped frames, because the frame-pool and encoder sizes diverge.

Scope of this issue

This is explicitly out of scope for #422, whose goal is "make window-target capture work end to end at startup". Resize-during-recording on a window target is a known limitation.

References

• PR fix(windows): respect window-scoped capture in native helper #422: fix(windows): respect window-scoped capture in native helper #422
• Comment: fix(windows): respect window-scoped capture in native helper #422 (comment)
• Microsoft docs –
• Microsoft docs –