Overview

When an ExponentialBackOff is configured with an initialInterval of 0
and a positive jitter, the first nextBackOff() throws
ArithmeticException: / by zero.

Both settings are individually accepted today:

• setJitter(...) only rejects negative values (Assert.isTrue(jitter >= 0, ...)).
• There is no validation on initialInterval, and with jitter = 0 an
  initialInterval of 0 already works and yields a delay of 0.

So the combination initialInterval = 0 and jitter > 0 is an accepted
configuration, yet it crashes instead of producing a delay — an inconsistency
between the two jitter branches.

Reproduction

ExponentialBackOff backOff = new ExponentialBackOff();
backOff.setInitialInterval(0);
backOff.setJitter(100);

backOff.start().nextBackOff(); // throws ArithmeticException: / by zero

Root cause

In ExponentialBackOff.ExponentialBackOffExecution#applyJitter:

long applicableJitter = jitter * (interval / initialInterval);

With initialInterval == 0, the first interval is also 0, so this evaluates
jitter * (0 / 0) — an integer division by zero.

Fix

Guard the division so no jitter scaling is applied when initialInterval is 0,
leaving behavior for positive intervals unchanged:

long applicableJitter = jitter * (initialInterval > 0 ? (interval / initialInterval) : 1);

A regression test (jitterWithZeroInitialInterval) is added to
ExponentialBackOffTests.

This is a narrow runtime-crash guard and is orthogonal to the validation design
discussed in #35357 — it stays compatible whichever way that validation is
ultimately implemented.