Mark Scout jobs as failed on timeout by default

[Bramvzw]

Follow-up to #1001, implementing the approach you suggested when closing it: no configuration, just failOnTimeout = true on the Scout jobs.

Fixes #957.

The property is set on the ConfiguresJobOptions trait, which covers MakeSearchable, RemoveFromSearch and their *Uniquely subclasses, and directly on MakeRangeSearchable since that job does not use the trait.

Why

When a Scout job exceeds its timeout on a queue with unlimited tries ('tries' => 0, common in Horizon supervisor configs), the job is never marked as failed: the worker is killed, the job is released back onto the queue after retry_after and picked up again, indefinitely. horizon:forget cannot help because the job never reaches failed_jobs. I verified this end-to-end on a fresh Laravel 12 app with the database queue driver and a deliberately slow toSearchableArray(): without this change the job stayed pending forever (six worker kills in 50 seconds, attempts climbing, failed_jobs empty); with this change the exact same scenario fails on the first timeout with a TimeoutExceededException in failed_jobs and the queue moves on.

Behavioral change

Scout jobs now fail on the first timeout — including under the default 60 second worker timeout — instead of being released for another attempt. Since indexing is idempotent, a failed job can simply be retried with queue:retry, and a job subclass can opt out by declaring public $failOnTimeout = false. One edge to be aware of: userland classes that use ConfiguresJobOptions directly and declare their own $failOnTimeout property (or redeclare it with a bool type) will hit PHP's trait property conflict and need a small adjustment.

Worth noting for completeness: a request that blocks forever inside a single I/O call is not interruptible by pcntl_alarm, so client-level timeouts on the search engine remain necessary for that case — this change closes the queue-side gap where a fired timeout still never failed the job.