As otherwise MITM proxies may translate this as server error
and produce 50x errors.

…n too, correct 401/403

Two follow-ups to review feedback on this PR:

- AccessTokenService#useAccessToken is now @transactional(TxType.REQUIRES_NEW).
  Without it, the setActive(false)/setAccessedTimestamp mutations joined the
  caller's transaction and were rolled back whenever createNamespace threw its
  own (expected) ErrorResultException right after - silently discarding the
  fact that an expired token was ever touched. Matches the same REQUIRES_NEW
  idiom already used by ExtensionScanPersistenceService for an identical reason.

- LocalRegistryService#publish now drains the request body before rejecting
  for a missing publisher agreement, not just for an invalid/expired token -
  eclipse.checkPublisherAgreement(...) can throw before content has been
  touched at all, reproducing the same early-response-unread-body problem
  this PR set out to fix.

Also audited 401 vs 403 usage across the token/permission code paths this PR
touches and found the same 'defaults to 400' gap in several more places:

- LocalRegistryService#verifyToken: a third invalid-token call site this PR
  didn't touch, now 401 for consistency with the other two; its own
  'insufficient access rights' check is now 403 (authenticated, not permitted).
- PublishExtensionVersionHandler#checkPublishPermission (shared by both the
  scan and non-scan publish paths): same 'insufficient access rights' fix, 403.
- EclipseService#checkPublisherAgreement (all 4 throw sites): 403, matching
  the sibling checkEclipseToken's existing 403 in the same file.

Updated the RegistryAPITest assertions that hard-coded the old status, and
the OpenAPI docs on verifyToken/publish, which were stale either way (the
/api/-/publish 400 doc still showed 'Invalid access token' as its example
despite this PR already making that case 401).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Addresses Copilot review feedback: the new expiration check used
isBefore(now), treating a token expiring at exactly now as still
valid. The rest of the codebase treats expiry as inclusive -
expireAccessTokens' "expires_timestamp <= ?1" and
findByExpiresTimestampLessThanEqualAndActiveTrueAndNotifiedFalseOrderById
both use <=. Switch to !isAfter(now) to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…over the size-limit test

Addresses two follow-ups from review:

- DrainOnCloseInputStream capped close()'s drain at maxBytes without
  accounting for bytes a caller already read normally beforehand.
  ExtensionService#createExtensionFile's own oversized-package detection
  already reads up to maxContentSize + 1 bytes before rejecting; without
  tracking cumulative reads, close() would then drain a fresh maxBytes
  on top, costing up to ~2x maxBytes total for exactly the case the
  bound exists to protect against. Now tracks bytesRead across the
  stream's whole lifetime (matching the existing SizeLimitInputStream
  in the same package) and only drains the remaining budget at close.
  Verified the regression test actually catches this: reverted the fix,
  watched it fail with the exact double-counted numbers, restored it.

- Added ExtensionServiceTest#shouldRejectAPackageExceedingTheMaxContentSize:
  no existing test exercised createExtensionFile's size-limit rejection
  itself (the one stub of getMaxContentSize() in this test class was
  incidental, for an unrelated precondition-check test). Verified
  empirically (mirroring the exact BufferedInputStream/ByteStreams.limit
  chain createExtensionFile builds) that reading past the cap through
  DrainOnCloseInputStream does not throw - only close() enforces the
  bound - so wrapping the test's content in DrainOnCloseInputStream
  with the same cap LocalRegistryService#publish uses makes the test
  match the real call path without changing its outcome.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

- DrainOnCloseInputStream's Javadoc claimed the total bytes read over
  the stream's lifetime is capped at maxBytes, but the class doesn't
  enforce a hard limit on normal reads - only close()'s own drain is
  bounded to whatever remains of the budget. Reworded to say that
  precisely: the total only stays near maxBytes in combination with a
  caller (like ExtensionService#createExtensionFile) that itself stops
  reading once it's seen enough to reject the request.

- testCreateNamespaceExpiredToken/testPublishExpiredToken used
  LocalDateTime.now() to set an expired timestamp, while
  AccessTokenService evaluates expiry against TimeUtil.getCurrentUTC().
  Not an actual flakiness risk in practice (minusDays(1) stays in the
  past under any real-world timezone offset), but a real inconsistency
  with what the code under test actually uses. Switched both to
  TimeUtil.getCurrentUTC().

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>