text-input: re-sync on enter and flag secure fields as Password

LTK drives the on-screen keyboard through zwp_text_input_v3: focusing a text widget enables text-input so the compositor's input-method (squeekboard) brings the keyboard up. Two gaps are fixed here.
Handle the `enter` event by re-emitting enable + content type + commit. The compositor sends `enter` when it (re)focuses the text input — notably when an input-method connects after the field has already enabled text-input (a startup race). LTK previously ignored `enter`, so that activation was lost and the keyboard never appeared; it now re-declares its state and the OSK comes up.
Declare the content type from the field's `secure` flag: secure fields are flagged `ContentPurpose::Password` with `ContentHint::SensitiveData | HiddenText` (so the IME/OSK skips prediction, autocorrect and storing the value), everything else stays `Normal`/`None`. The content type is also refreshed when focus moves between two text fields (e.g. username → password) without re-creating the text-input object, and a new `AppData::text_input_secure` lets the `enter` re-emit path preserve the current field's type.
Correct the docs: `TextEdit::secure()` and SECURITY.md claimed secure "skips text-input-v3 registration". It does not — the field still activates text-input so the OSK works on it; the protection is the Password / sensitive flagging, and the value still reaches a trusted compositor/IME.

SECURITY.md

@@ -71,8 +71,13 @@ message and we will reply with it before sharing any sensitive details.
   replaces the previous frame's snapshot, so the typical lifecycle is
   "one frame on the heap, then overwritten on drop". Single-line and
   multiline are mutually exclusive with secure (passwords have no line
-  breaks); the text-input-v3 IME path is also skipped in secure mode so
-  preedit / commit strings never reach the compositor's IME stack.
+  breaks). Note: secure does **not** skip the text-input-v3 path — the
+  field still activates it (so the on-screen keyboard works on password
+  fields) but is flagged `Password` with `SensitiveData | HiddenText`,
+  which asks the IME / OSK not to predict, autocorrect or store the
+  value. The value can still reach a trusted compositor/IME; closing
+  that path would mean not activating text-input there (and losing the
+  OSK on the field).
 
   ### What `TextEdit::secure` does **not** cover