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/event_loop/run.rs

@@ -277,6 +277,7 @@ pub( crate ) fn try_run<A: App>( app: A ) -> Result<(), RunError>
 		current_cursor_shape:       None,
 		text_input_manager,
 		text_input:         None,
+		text_input_secure:  false,
 		activation_state,
 		activation_token_pending,
 		data_device_manager,
@@ -809,6 +810,7 @@ pub( crate ) fn try_run<A: App>( app: A ) -> Result<(), RunError>
 					}
 				}
 			}
+			eprintln!( "ltk: focus_request id={:?} resolved={}", id, hit.is_some() );
 			if let Some( ( focus, flat_idx ) ) = hit
 			{
 				let qh = data.qh.clone();