fix: clipboard request leak when embedder dismisses confirmation dialog

[daiimus]

Summary

In embedded.zig:800-834, when completeClipboardRequest throws UnsafePaste or UnauthorizedPaste, the state pointer is NOT freed (the defer is skipped via early return). The expectation is the embedder will call ghostty_surface_complete_clipboard_request again with the confirmation.

If the embedder dismisses the confirmation dialog without calling back, the ClipboardRequest allocation leaks permanently.

Fix

Either:

1. Provide an explicit ghostty_surface_cancel_clipboard_request(state) API for the dismiss case.
2. Track outstanding clipboard requests on the surface and clean them up in deinit.

Severity

MEDIUM — Memory leak per dismissed clipboard confirmation. Accumulates over time.

Source

Identified during code review of daiimus/ghostty:ios-external-backend.

[daiimus]

Verification

Confirmed the completeClipboardRequest pattern at embedded.zig:800-834. When UnsafePaste or UnauthorizedPaste is thrown, the function returns early (line 825), skipping the alloc.destroy(state) at line 833. The state pointer is passed to the embedder's confirm_read_clipboard callback with the expectation that it will be passed back in a subsequent call.

However, this is an upstream bug, not fork-specific. The exact same code exists in upstream's embedded.zig. Our fork has not modified completeClipboardRequest.

Practical impact for iOS

On iOS, if the user dismisses the clipboard confirmation dialog without calling back, the ClipboardRequest leaks. Each leak is small (one allocation) but accumulates over the app's lifetime. In practice, clipboard paste confirmations are rare on iOS, so this is low-impact.

Recommendation

Keep open but add upstream label. Same class of issue as #181 — real leak, upstream origin, low practical impact for our use case.