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.

src/widget/text_edit/mod.rs

@@ -346,10 +346,14 @@ impl<Msg: Clone> TextEdit<Msg>
 	///   the credential mount, and restrict core-dump capability with
 	///   `prctl( PR_SET_DUMPABLE, 0 )` on the process.
 	/// * **Compositor-side records.** Wayland text-input protocols can
-	///   surface preedit / commit strings to the compositor's IME
-	///   stack; `secure` skips text-input-v3 registration so this path
-	///   stays closed. Verify your compositor honours that — most do,
-	///   but the protocol does not strictly require it.
+	///   surface preedit / commit strings to the compositor's IME stack.
+	///   `secure` does *not* suppress text-input-v3 — the field still
+	///   registers so the on-screen keyboard activates on it — but it is
+	///   flagged `Password` with `SensitiveData | HiddenText`, asking the
+	///   IME / OSK to skip prediction, autocorrect and storing the value.
+	///   The value still reaches the (trusted) compositor/IME; for a
+	///   stricter threat model, suppress text-input on secure fields
+	///   instead (at the cost of losing the OSK there).
 	///
 	/// See the in-repo `SECURITY.md` for the full threat-model write-up
 	/// (the *Hardening features* section enumerates each guarantee and