Whitelist values ignored: spambot_check_whitelist() reads the wrong config keys

Problem/Motivation

The settings form saves the IP/email/username whitelists to *_list config keys, but spambot_check_whitelist() reads non-_list keys, which are never written. Every whitelisted value therefore returns FALSE, so whitelists are silently ignored and whitelisted users can still be blocked at registration.

Two smaller defects in the same code: strpos() does substring matching (a whitelisted 8.8.8.8 would match 18.8.8.8), and the *_list keys in spambot.schema.yml are bare sequences with no element type.

This is a port regression. Whitelist storage was migrated from newline-delimited strings to config sequences (*_list) in spambot_update_8004(), and the settings form and its #default_values were updated to match. spambot_check_whitelist() was not, so it still reads the obsolete pre-migration keys.

Steps to reproduce

1. Add allow@example.com to the email whitelist and save.
2. spambot_check_whitelist('email', \Drupal::config('spambot.settings'), 'allow@example.com');
3. Returns FALSE; expected TRUE.

Proposed resolution

Read the *_list keys and match exactly with a strict in_array():

function spambot_check_whitelist($type, $config, $value) {
  switch ($type) {
    case 'ip':
      $whitelist = $config->get('spambot_whitelist_ip_list');
      break;

    case 'email':
      $whitelist = $config->get('spambot_whitelist_email_list');
      break;

    case 'username':
      $whitelist = $config->get('spambot_whitelist_username_list');
      break;

    default:
      return FALSE;
  }

  return is_array($whitelist) && in_array($value, $whitelist, TRUE);
}

Also add element types (type: string) to the three schema sequences in spambot.schema.yml. The MR includes a kernel test covering all three whitelist types plus the exact-match guard.