incident_components keeps an index that the July composite unique now covers

`incident_components` has a single column index on `incident_id`, from `2017_07_18_214718_CreateIncidentComponents.php`:

```php
$table->integer('incident_id')->unsigned()->index();
```

Since `2026_07_25_000002_add_constraints_to_component_pivots.php` added the unique on `(incident_id, component_id)`, that older index is a left prefix of the unique. MySQL and PostgreSQL can both answer a query filtering on `incident_id` alone from the composite, so the single column index no longer adds a read path. It is still maintained on every insert and update to the pivot, and still takes space.

Nothing here was written wrong. The composite arrived nine years after the single index, which is the ordinary way this happens.

`schedule_components` is not affected. It was constrained in the same migration, but its 2016 migration adds no single column indexes, so there is nothing to remove there.

The fix is to drop the index. An existing install needs a follow up migration; for new installs it is removing `->index()` from the 2017 migration, though you may prefer not to edit a historical one.

Found with [Laravel Truss](https://github.com/albertoarena/laravel-truss), a structure only schema linter, running `truss:doctor` against a Cachet install. Checked against `main` today.

Start by reading 2017_07_18_214718_CreateIncidentComponents.php and 2026_07_25_000002_add_constraints_to_component_pivots.php, then run the schema checks with Laravel Truss's truss:doctor. Determine the migration path for existing installs and the fresh-install schema change. Done means incident_components no longer has the redundant single-column index while the composite unique remains intact.

Written by the indexing model from the issue text.