Avoid int overflow in expiration time calculations

[a-kogun]

Two places still compute an expiration time by multiplying an int
number of seconds by 1000 without widening to long:

• FlashMap.startExpirationPeriod(int) (spring-webmvc)
• MockMvcWebConnection.createCookie(...) (spring-test)

Above 2_147_483 seconds (~24.9 days) the multiplication overflows and
yields a negative offset, so the expiration time lands in the past.
With Integer.MAX_VALUE, timeToLive * 1000 evaluates to -1000, i.e.
one second ago.

Impact

• FlashMap: a timeout set via the public
  AbstractFlashMapManager.setFlashMapTimeout(int) is treated as
  already expired, so flash attributes are silently dropped.
• MockMvcWebConnection: because storeCookies compares the computed
  expiry against now, a cookie with a large max-age is passed to
  cookieManager.removeCookie(...) instead of addCookie(...) — the
  cookie is discarded rather than stored.

Fix

Widen the literal to 1000L in both places. This is the same change
already applied to this exact pattern in gh-25613
(ExecutorConfigurationSupport.setAwaitTerminationSeconds(int) and
AbstractResourceBasedMessageSource.setCacheSeconds(int)), and matches
how those methods read today.

Tests

Two regression tests are included, both of which fail before the change:

• FlashMapTests.notExpiredWithLargeTimeToLive() — fails with
  Expecting actual: <now-1000> to be greater than: <now>.
• MockMvcWebClientBuilderTests.cookieWithLargeMaxAgeIsStored() — fails
  with expected: "foo" but was: "NA", showing the cookie was dropped.

A scan of src/main/java found no other live instances of this pattern:
AbstractSockJsService.ONE_YEAR and DurationFormatterUtils.micros are
already declared long.