fix: Prevent panic on nil item during shutdown (#1257)

A race condition existed where the ShardProcessor could panic if a `nil`
flowItem was present in its enqueue channel during shutdown.

The main `Run` loop correctly checked for and handled `nil` items, but
the channel drain loop within the `shutdown` method did not. If a
context cancellation or other shutdown signal occurred before the main
loop could process the `nil` item, the shutdown logic would read the
`nil` from the channel and attempt to call `item.finalize()`, resulting
in a nil pointer dereference.

This bug was exposed by a flaky test, which was difficult to reproduce
locally because of its timing-dependent nature. The test enqueues a
`nil` item and then uses a `time.Sleep(50ms)` to allow the processor's
`Run` loop to handle it before the test harness is stopped.

On a typical developer machine, 50ms is ample time for the `Run` loop
to win this race. However, in a resource-constrained CI environment,
goroutine scheduling can be less predictable. The `Run` loop could be
delayed, allowing the 50ms sleep to expire and the test to initiate
shutdown first. This triggered the panic, explaining why the flake
appeared primarily in the CI/CD environment.

This commit resolves the underlying bug by adding a `nil` check to the
drain loop inside the `shutdown` method. This makes the shutdown process
robust against this race condition, fixing the production code and
stabilizing the test regardless of environment timing.

Author: LukeAVanDrie

pkg/epp/flowcontrol/controller/internal/processor.go

@@ -549,6 +549,9 @@ func (sp *ShardProcessor) shutdown() {
 		for {
 			select {
 			case item := <-sp.enqueueChan:
+				if item == nil { // This is a safeguard against logic errors in the distributor.
+					continue
+				}
 				item.finalize(types.QueueOutcomeRejectedOther,
 					fmt.Errorf("%w: %w", types.ErrRejected, types.ErrFlowControllerShutdown))
 			default: