wl: a content purpose belongs to its activation

pendingpurpose was never cleared, and sway sends content_type only when
the text input asked for one: active_features is frozen at the enable
commit (wlr_text_input_v3.c) and relay_send_im_state tests it before
sending.  So a client that sets no content type leaves the last client's
purpose standing -- and after a GTK password entry that purpose is
password, so every key in the next window was forwarded raw and strans
looked dead there until a client that does declare one took the focus.

A purpose is per activation, as it is per context in ibus.c.  Clearing it
on activate is enough: the content type, if any, arrives after the
activate and before the done that applies both.

The sway runs could not have found this; the password client was GTK,
which always declares.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

wl.c

@@ -387,11 +387,17 @@ flushpending(void)
 	takedraw();
 }
 
+/*
+ * A purpose belongs to the activation: the compositor sends a content type
+ * only for a client that asked for one, so a client that asks for none has
+ * none, whatever the last one wanted.
+ */
 static void
 imactivate(void*, struct zwp_input_method_v2*)
 {
 	pendingactive = 1;
 	activated = 1;
+	pendingpurpose = 0;
 }
 
 static void