fix(pendinguploads): use 100ms ticker in TickerFiresAdditionalCycles test

TestStartSweeperWithInterval_TickerFiresAdditionalCycles was flaky on
loaded CI runners because it called StartSweeperForTest, which passes
SweepInterval (5 minutes) as the ticker interval. The test expects ≥2
cycles in a 2-second window, but a 5-minute ticker fires 0-1 times
under CPU contention, causing "waited 2s for 2 sweep cycles, got 1".

Fix: call StartSweeperWithIntervalForTest directly with a 100ms ticker
interval, which is the intended test-harness pattern (per the export_test
comment). The done-channel teardown (cancel + <-done) is preserved.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

workspace-server/internal/pendinguploads/sweeper_test.go

@@ -190,7 +190,14 @@ func TestStartSweeperWithInterval_TickerFiresAdditionalCycles(t *testing.T) {
 	ctx, cancel := context.WithCancel(context.Background())
 	defer cancel()
 
-	done := pendinguploads.StartSweeperForTest(ctx, store, time.Hour)
+	// Use a short ticker interval (100ms) so the test runs fast without
+	// burning real wall-clock time. StartSweeperWithIntervalForTest is the
+	// test-friendly variant that accepts a caller-specified interval; the
+	// production SweepInterval of 5m is too coarse for a 2s deadline on
+	// a loaded CI runner (the ticker may not fire at all under CPU
+	// contention — the root cause of the pre-existing CI flake).
+	done := make(chan struct{})
+	go pendinguploads.StartSweeperWithIntervalForTest(ctx, store, time.Hour, 100*time.Millisecond, done)
 	// Immediate cycle + at least one tick-driven cycle.
 	store.waitForCycle(t, 2, 2*time.Second)