Consider finalizing the customEditorDiffs API

Would it make sense to start the API finalization process for the proposed `customEditorDiffs` API?

The proposal was implemented in #298924 and is also being exercised by the Markdown custom diff work tracked in #315174. The public `vscode.proposed.customEditorDiffs.d.ts` API surface also appears to have remained unchanged since June.

Related custom editor API work has progressed as well. In particular, the per-editor-type priority API from #292379 has already gone through API finalization, and recent work has also improved custom diff editor selection and binary diff fallback behavior (#324791, #324804).

There is also at least one external extension using `customEditorDiffs` for a non-text document workflow. Academic PDF Viewer (`ovolab-veritas.academic-pdf-viewer`) uses `resolveCustomEditorSideBySideDiff` to render Git revisions of PDFs side by side, with document-aware change highlighting and synchronized navigation:

https://github.com/VeriTas-arch/academic-pdf-viewer

For binary and structured document editors, this API fills an important gap: extensions need access to both sides of a diff and, depending on the use case, either a unified custom diff surface or coordinated side-by-side custom editor surfaces.

From an extension author's perspective, the current API shape has worked well for this use case.

Would the team be open to starting finalization of `customEditorDiffs`? If there are still API design concerns or additional scenarios that should be validated before finalization, I'd be happy to help test them from an external extension.