PostgresPgvectorClient::updateFields() ignores the configured field type for processor-defined fields

Problem/Motivation

PostgresPgvectorClient::updateFields() ignores the configured field type for processor-defined fields (Search API
ProcessorProperty) and always creates the column as VARCHAR. The relevant fallback in
src/PostgresPgvectorClient.php:

if (!method_exists($field_data_definition, 'getFieldDefinition')) {                                                             
    $this->addFieldIfNotExists(FALSE, 'string', $field->getFieldIdentifier(), $collection_name, $connection);                          
    continue;                                                                                                                                
  }

The hard-coded 'string' overrides whatever the index YAML declares (e.g. type: integer). At index time,
integer values are silently coerced to numeric strings. At query time, Search API emits comparisons with integer literals, and Postgres
aborts with operator does not exist: character varying = integer. The query fails and the calling view returns zero results
with no visible error to end users.

Steps to reproduce

1. Create a Search API index backed by ai_vdb_provider_postgres.
2. Add a custom processor that exposes a ProcessorProperty with 'type' => 'integer' and
   

   'is_list'    
     => FALSE

   .

3. Index any content so the field is added to the collection table.
4. Inspect the column:
   

   SELECT data_type FROM information_schema.columns WHERE table_name = '<collection>' AND column_name = 
     '<field>';

   — it is character varying, not integer.

5. Run a query with an integer condition on that field via the Search API query builder. Postgres returns
   

   operator does not exist:
      character varying = integer

   .

Proposed resolution

In the fallback branch, honor the Search API field's declared type instead of hard-coding 'string':

if (!method_exists($field_data_definition, 'getFieldDefinition')) {                                                             
    $this->addFieldIfNotExists(FALSE, $field->getType(), $field->getFieldIdentifier(), $collection_name, $connection);              
    continue;                                                                                                                                
  }

$field->getType() already returns the configured Search API type (integer, decimal,
date, boolean, text, string) and maps cleanly through DATA_TYPE_MAPPING.
Cardinality detection for processor properties may also need attention (the fallback assumes single-value); consider reading
'is_list' from the ProcessorProperty settings to set $isMultiple.

Remaining tasks

• Patch updateFields() as above.
• Add a kernel test covering processor-defined integer / decimal / boolean / date fields.
• Document an upgrade path for sites that already have a VARCHAR column from this bug (drop dependent indexes,
  

  ALTER
     COLUMN ... TYPE ... USING ...::<type>

  , recreate indexes).

User interface changes

None.

API changes

None for module consumers. Internal: the fallback in updateFields() now passes the field's declared type rather than
'string'.

Data model changes

New collections will create columns with the correct Postgres type for processor-defined non-string fields. Existing collections are
unchanged by this patch — site owners must run a one-time ALTER COLUMN to fix columns already created as
VARCHAR.