stabilize client reindexer test

A reindexer test was asserting the wrong contract for
`Reindexer.TestSignals.Reindexed`. The test waited twice on the signal
as though it fired once per index or once per startup cycle, but the
reindexer sends it once after a run has finished processing all
configured indexes.

In the failing run, the client logged a complete reindex pass, including
`Initiated reindex` for every default index, and then the test timed out
waiting for another signal that would never arrive:

https://github.com/riverqueue/river/actions/runs/24406465152

Configure the client with a single reindex target and wait for one
`Reindexed` signal. That keeps this test focused on what it actually
owns, which is proving that the client wires up the reindexer and lets a
run complete through the full stack.

The more detailed scheduling and multi-index behavior stay covered by
the dedicated reindexer tests, so this client-level assertion no longer
depends on the size of the default index list or on how long a full
reindex pass happens to take on CI.

Author: bgentry

client_test.go

@@ -5559,15 +5559,16 @@ func Test_Client_Maintenance(t *testing.T) {
 		t.Parallel()
 
 		config := newTestConfig(t, "")
+		config.ReindexerIndexNames = []string{"river_job_kind"}
 		config.ReindexerSchedule = &runOnceSchedule{}
 
 		client, _ := setup(t, config)
 
 		startAndWaitForQueueMaintainer(ctx, t, client)
 
 		svc := maintenance.GetService[*maintenance.Reindexer](client.queueMaintainer)
-		// There are two indexes to reindex by default:
-		svc.TestSignals.Reindexed.WaitOrTimeout()
+		// This client test only needs to prove the reindexer is wired up
+		// end-to-end. Use one configured index so it stays fast.
 		svc.TestSignals.Reindexed.WaitOrTimeout()
 	})
 }