Summary

Fixes database query failures when getScoutKeyName() is overridden to return a different field name than the model's actual primary key. Database operations (chunking, ordering, whereIn) were incorrectly using the Scout key name instead of the database primary key.

Fixes #960

Problem

When a model overrides getScoutKeyName() to return a search-engine-specific field name that differs from the database primary key, all database operations break:

class Product extends Model
{
    protected $primaryKey = 'uuid';

    public function getScoutKeyName(): string
    {
        return 'id'; // Meilisearch document ID field
    }
}

// scout:import fails:
// SQLSTATE: Column not found: 1054 Unknown column 'id' in 'order clause'
// Because chunkById() uses getScoutKeyName() ('id') instead of getKeyName() ('uuid')

Solution

Separate the two concerns across all affected files (SearchableScope, Searchable trait, QueueImportCommand, MakeRangeSearchable, DatabaseEngine, CollectionEngine):

• Search engine operations (indexing, deleting documents, extracting IDs from search results): continue using getScoutKeyName()
• Database operations (chunking, ordering, whereIn, min/max): now use getKeyName()

Before/After

Before: scout:import with a custom getScoutKeyName() fails with "Column not found" because database queries use the Scout key name.

After: Database queries use the model's actual primary key. Search engine operations continue using the Scout key name. Both work independently.

Test Plan

• Verify scout:import works with default configuration (getScoutKeyName == getKeyName)
• Verify scout:import works when getScoutKeyName differs from getKeyName
• Verify DatabaseEngine and CollectionEngine search results are correctly ordered
• Run existing test suite