New IME API is too restrictive

In short, I want to use the "cursor area" capability, but provide the area through an update later. The old v0.30.x IME API allowed that and it worked.

With the new API:

    let capabilities = ImeCapabilities::new().with_hint_and_purpose().with_cursor_area();
    let data = ImeRequestData::default().with_hint_and_purpose(hint, purpose);
    let req = ImeEnableRequest::new(capabilities, data.clone()).unwrap();

fails to unwrap() because I haven't provided the cursor area yet. Alternatively if I don't unable .with_cursor_area() then I get errors later:

2025-11-17T14:30:07Z WARN  winit_wayland::seat::text_input] discarding IME cursor area update without capability enabled.

Given that hint, purpose and surrounding text are widget-level details (content) while position is a window-level detail (a widget has no idea what translations may have been used), I find it surprising that both constructs are tied into the same "update". Essentially it forces me to keep a copy of the widget-level details at the window-level.

Also, why can ImeEnableRequest::new fail in the first place? Why even require that capabilities be specified explicitly if the specification requires that they match provided data exactly — can we not just implement From<ImeRequestData> for ImeEnableRequest?

Start with the ImeCapabilities, ImeRequestData, and ImeEnableRequest APIs shown in the issue, and compare their behavior with the old v0.30.x IME API. Reproduce the unwrap failure and the winit_wayland warning, then determine an API design that permits the cursor area to be supplied later without requiring duplicated widget-level data; the specification's capability and data requirements should remain satisfied.