protocol: ENS name from ContactUpdate is never queued for verification

[at0m1x19]

Summary
When a contact's ENS name arrives via a ContactUpdate message, the handler stores the
name and marks it unverified, but never queues it for verification. The background
verification loop only checks queued names, so the name stays ensVerified: false forever.

Details

• protocol/messenger_handler.go:1206-1209 (HandleContactUpdate): sets contact.EnsName
  and contact.ENSVerified = false, but does not call m.ensVerifier.Add(...).
• The chat-message path (handleChatMessage) does it correctly:
  protocol/messenger_handler.go:2297 calls m.ensVerifier.Add(contact.ID, ...).
• Add writes the "to be verified" record (protocol/ens/persistence.go:103) that the
  verifier's 30s loop reads via GetENSToBeVerified (protocol/ens/verifier.go:177);
  without it the loop has nothing to verify.
• The downstream machinery works: once verification completes, the subscriber
  (protocol/messenger.go:1286-1310) updates the contact and signals the client.
• The chat-message path is currently moot anyway: status-go never sets EnsName on
  outgoing chat messages, so ContactUpdate is the only way a peer's ENS name arrives —
  meaning automatic ENS verification effectively never runs.

Impact
Contacts who share an ENS name via contact update are never shown as ENS-verified; clients
can only work around it by calling the wakuext_ensVerified RPC manually.

Found in
Discovered while writing ENS functional tests in
#7372
(review thread: #7372 (comment)).