Bumps the github-actions group with 6 updates:

| Package | From | To |
| --- | --- | --- |
| [github/codeql-action/init](https://github.com/github/codeql-action) | `4.37.3` | `4.37.4` |
| [github/codeql-action/analyze](https://github.com/github/codeql-action) | `4.37.3` | `4.37.4` |
| [actions/setup-java](https://github.com/actions/setup-java) | `5.6.0` | `5.7.0` |
| [gradle/actions/setup-gradle](https://github.com/gradle/actions) | `6.2.0` | `6.3.0` |
| [docker/login-action](https://github.com/docker/login-action) | `4.5.1` | `4.6.0` |
| [j178/prek-action](https://github.com/j178/prek-action) | `2.0.6` | `3.0.0` |


Updates `github/codeql-action/init` from 4.37.3 to 4.37.4
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@e4fba86...f205ea1)

Updates `github/codeql-action/analyze` from 4.37.3 to 4.37.4
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@e4fba86...f205ea1)

Updates `actions/setup-java` from 5.6.0 to 5.7.0
- [Release notes](https://github.com/actions/setup-java/releases)
- [Commits](actions/setup-java@03ad4de...b6effb0)

Updates `gradle/actions/setup-gradle` from 6.2.0 to 6.3.0
- [Release notes](https://github.com/gradle/actions/releases)
- [Commits](gradle/actions@3f131e8...9c97196)

Updates `docker/login-action` from 4.5.1 to 4.6.0
- [Release notes](https://github.com/docker/login-action/releases)
- [Commits](docker/login-action@abd2ef4...dbcb813)

Updates `j178/prek-action` from 2.0.6 to 3.0.0
- [Release notes](https://github.com/j178/prek-action/releases)
- [Commits](j178/prek-action@5337cb9...4e14d07)

---
updated-dependencies:
- dependency-name: github/codeql-action/init
  dependency-version: 4.37.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: github-actions
- dependency-name: github/codeql-action/analyze
  dependency-version: 4.37.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
  dependency-group: github-actions
- dependency-name: actions/setup-java
  dependency-version: 5.7.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: github-actions
- dependency-name: gradle/actions/setup-gradle
  dependency-version: 6.3.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: github-actions
- dependency-name: docker/login-action
  dependency-version: 4.6.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: github-actions
- dependency-name: j178/prek-action
  dependency-version: 3.0.0
  dependency-type: direct:production
  update-type: version-update:semver-major
  dependency-group: github-actions
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* feat: removing extension overview sidebar intermediate state

* fix: use consistent gap-based spacing for sidebar groups at every breakpoint

resourcesGroup's own mb: { xs: 2, sm: 2, md: 0, lg: 0, xl: 2 } was a
leftover from when the sidebar groups were laid out in a row at
md/lg (no vertical margin needed there). Now that the sidebar is
unconditionally a column at every breakpoint, that split meant md/lg
groups got only the parent's gap: 2 (16px) while xs/sm/xl groups got
gap: 2 plus their own mb: 2 stacked on top (32px) - reintroducing the
same tablet-vs-desktop inconsistency this PR removes elsewhere.

Drop mb entirely and let the parent's gap: 2 be the sole source of
spacing between groups, consistently at every breakpoint.

Refs #2068

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

---------

Co-authored-by: Thomas Neidhart <thomas.neidhart@eclipse-foundation.org>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ses (#2073)

* fix: stamp a fixed api-version on Gallery JSON responses to keep compression working

Real VS Code clients rely on the Gallery API's response Content-Type
carrying an api-version media type parameter, e.g.
application/json;api-version=3.0-preview.1, matching the real VS Code
Marketplace. Spring's content negotiation already gets most of the way
there on its own: a requested media type with more parameters is
considered "more specific" than the plain type declared via produces,
so it echoes the client's Accept-header parameter back verbatim.

Relying on that echo is fragile in two ways: it depends entirely on
whatever the client happened to send (or omitted), and it makes the
response Content-Type client-controlled, which breaks compression.
Jetty 12.1's new CompressionHandler (pulled in by the Spring Boot 4
migration) matches Content-Type against server.compression.mime-types
with an exact string comparison after stripping only the charset
parameter - any other parameter left in place, like an arbitrary
echoed api-version, fails that match and silently disables compression
for these responses. There is no way to enumerate every value a client
might send, so compression could never reliably apply to them.

Add VSCodeGalleryContentTypeAdvice, a ResponseBodyAdvice scoped to
VSCodeAPI that always stamps the server's own, fixed
IVSCodeService.GALLERY_API_VERSION onto JSON Gallery responses,
regardless of what the client asked for. That keeps the Content-Type a
single known literal - application/json;api-version=3.0-preview.1 -
which needs to be added to server.compression.mime-types alongside
application/json for compression to apply to these responses.

Also promotes the previously VSCodeIdService-private API_VERSION
constant to IVSCodeService.GALLERY_API_VERSION, shared between the
outgoing upstream requests and this server's own Gallery responses.

Fixes #2071

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

* test: prove compression against the real Jetty CompressionHandler

MockMvc-based tests never touch the actual Jetty handler chain that
performs response compression, so they can assert the Content-Type
header is correct but can't prove compression itself still works.

Add VSCodeGalleryCompressionTest, which boots a real embedded Jetty
server via JettyServletWebServerFactory - the same class Spring Boot 4
wires up server.compression through - and shows:

- with only "application/json" configured (the Spring Boot 3 / Jetty
  12.0 setup), a response whose Content-Type is
  "application/json;api-version=3.0-preview.1" (what
  VSCodeGalleryContentTypeAdvice now stamps) is NOT compressed;
- adding that exact literal to the configured mime types restores
  compression, and the resulting body is genuinely valid gzip that
  decodes back to the original JSON.

Refs #2071

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

* feat: compress the Gallery API's versioned Content-Type without config changes

VSCodeGalleryContentTypeAdvice needs application/json;api-version=3.0-preview.1
added to server.compression.mime-types for Jetty 12.1's CompressionHandler
to compress those responses (exact string match, only charset stripped).
That requires every deployment's config to know about a VS Code Gallery
API implementation detail.

Add VSCodeGalleryCompressionConfig instead: a
WebServerFactoryCustomizer<ConfigurableJettyWebServerFactory> that, once
spring-boot-jetty has installed its CompressionHandler from whatever
server.compression.* is configured, reads back that installed
CompressionConfig and replaces it with an equivalent one that
additionally includes the Gallery API's fixed Content-Type - so
compression works for it regardless of server.compression.mime-types.
If compression is disabled, no CompressionHandler is installed and this
is a no-op.

This trades a config-only fix for a code-only one: it adds a
compile-time dependency on jetty-compression-server (otherwise only a
transitive runtime dependency of spring-boot-starter-jetty) and reaches
into Jetty-specific classes. Verified end-to-end against a real
embedded Jetty server, and against the full application context booted
on Jetty (IntegrationTest).

Refs #2071

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

* fix: guard VSCodeGalleryCompressionConfig on Jetty being on the classpath

It unconditionally imported Jetty-specific classes
(org.eclipse.jetty.compression.server.CompressionHandler/CompressionConfig,
org.springframework.boot.jetty.ConfigurableJettyWebServerFactory), so a
hypothetical deployment without spring-boot-starter-jetty (Tomcat,
Undertow, or a test slice that doesn't pull it in) would fail to start
with a NoClassDefFoundError merely loading this configuration class,
rather than gracefully doing nothing.

Add @ConditionalOnClass on both types this class touches, matching the
project's own convention (see JedisClusterBucket4jConfiguration). Add
VSCodeGalleryCompressionConfigTest, using ApplicationContextRunner +
FilteredClassLoader, to prove the guard actually skips the
configuration when Jetty's compression support isn't on the classpath,
and still registers it when it is.

Refs #2071

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

* test: add end-to-end proof that /vscode/gallery/extensionquery is compressed

VSCodeGalleryCompressionTest already proves the compression mechanism
works, but against a synthetic servlet, not the real application.

Add VSCodeGalleryExtensionQueryCompressionIntegrationTest: boots the
full app (real embedded Jetty, real VSCodeGalleryContentTypeAdvice and
VSCodeGalleryCompressionConfig wiring, real database-backed search) and
sends an actual HTTP request to /vscode/gallery/extensionquery with
server.compression.mime-types deliberately left at the bare
application/json a Spring Boot 3-era config would have had. Confirms
the response comes back Content-Encoding: gzip and genuinely decodes
to valid JSON, plus a sanity check that omitting Accept-Encoding
correctly gets an uncompressed response.

Refs #2071

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

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

* bug: consume request body before sending response

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

* fix: preserve token expiry mutation, drain body on agreement rejection 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>

* fix: match the project's inclusive expiry boundary in useAccessToken

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>

* refactor: generalize body draining with DrainOnCloseInputStream

The manual try/catch-and-drain in publish()'s catch block only covered
the two rejection sites it explicitly wrapped, and didn't help with
the pre-existing gap in ExtensionService#createExtensionFile (an
oversized-package rejection only reads up to maxContentSize + 1 bytes,
leaving anything beyond the cap unread).

Add DrainOnCloseInputStream, a small FilterInputStream that drains any
remaining unread bytes in close(). Wrap the request body with it once,
at the top of publish(), and rely on try-with-resources to close it on
every exit path - success, an early rejection, or a validation failure
deep inside extensions.publishVersion(...). This replaces the ad hoc
drain-on-catch with a structural guarantee that can't be forgotten by
a future validation check, and - confirmed with a test mirroring
createExtensionFile's exact BufferedInputStream/size-capped-view chain
- also fixes the oversized-package gap, without ExtensionService
needing to know about it.

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

* fix: bound DrainOnCloseInputStream's drain to total lifetime bytes, cover 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>

* docs+test: address Copilot's suppressed review comments

- 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>

---------

Co-authored-by: Thomas Neidhart <thomas.neidhart@eclipse-foundation.org>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

* feat: Add GDPR endpoint to openvsx admin API

Adds a GDPR endpoint to the OpenVSX API that allows for admin level
tokens to request for users to be forgotten. Rather than deleting users,
this request will scrub all PII from the existing user records to erase
any potential leak of private information. This is done to best retain
things like reviews and other user actions within the system while
abiding by GDPR requirements.

These deletion requests do not remove or modify any of the internal
logging that already exists as there is a business need to retain that
type of data, which will have it's own retention policy that will
eventually purge those records.

Assisted-by: Claude Sonnet 4.6

* fix: Switch GDPR to use username instead of authId for ease of use

* fix: Update GDPR extension handling to delete versions

Based on feedback from Thomas N, the behaviour to deactivate extension versions in owned namespaces switched to instead delete versions published by the removed user. This is more inline with legal requirements as the removal of the Open VSX PA would revoke our right to publish the versions by the user.

* fix: Remove call to clear publisher agreement from GDPR functions

* chore: fix import order and formatting after rebase

Rebase conflict resolution in AdminService.java and AdminAPITest.java
restored an import order/style that doesn't match the repo's enforced
jbang import-sort/formatter (server/scripts/format.sh), which caused
the analyse CI check to fail. Ran the actual formatter to fix.

* chore: fix Eclipse formatter drift in AdminAPI.java

Annotation-argument indentation had drifted from the current Eclipse
formatter config; jbang-fmt normalizes it. Verified with prek run
--from-ref against main: all hooks pass now.

* cleanups

* feat: Delete user row entirely when GDPR erasure leaves no references

forgetUser previously always anonymized the UserData row in place, even
when nothing in the database still referred to it (e.g. a user who never
published, reviewed, or acted as an admin). Now it checks for remaining
references - reviews, removed-by markers on extension versions, admin
scan/file decisions, audit log entries, and retained (scrubbed) access
tokens - and deletes the row outright when none remain, falling back to
anonymization otherwise.

Adds countByUser/countByDecidedBy/countByRemovedBy repository queries
and RepositoryService wrappers to check for each.

* doc: Explain why scrubbed token values are kept, not nulled

generateTokenValue() checks hasAccessToken(value) across all tokens,
active or not, to avoid ever reissuing a value already handed out.
Nulling the value on scrub would let that check miss a token's old
value and let it be handed out again.

* test: Exercise the new forgetUser reference-count queries in the smoke test

RepositoryServiceSmokeTest asserts every public RepositoryService method
gets invoked, to catch query/schema mismatches. It was failing after the
last commit added countReviews/countVersionsRemovedBy/
countAdminScanDecisions(UserData)/countFileDecisions(UserData)/
countPersistedLogs without exercising them here.

* add Forget User button to the publisher admin page

---------

Co-authored-by: Thomas Neidhart <thomas.neidhart@eclipse-foundation.org>

* build: Update check script

That could be incorporated into commit hooks.

* Tie into hooks

* Revert "Tie into hooks"

This reverts commit 6b82934.

* Add to script

* print status after checking dependencies

* Use new --force-updates

* add dependency-override-check.sh, do not rely on a checked in version of the update check

---------

Co-authored-by: Thomas Neidhart <thomas.neidhart@eclipse-foundation.org>

* Add SBOM generation workflows for docker, gradle and yarn

Add three GitHub Actions workflows that generate and upload CycloneDX
SBOMs for 5 products to the eclipse-csi upload-sbom endpoint:

- sbom-docker.yml: scans published server/webui docker images, triggered
  by registry_package events (upstream only) or manual dispatch
- sbom-gradle.yml: SBOM for the gradle-based server component
- sbom-yarn.yml: SBOMs for the yarn-based cli/webui components

Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Lukas Puehringer <lukas.puehringer@eclipse-foundation.org>

* Drop 'staging: true' in sbom upload

Signed-off-by: Lukas Puehringer <lukas.puehringer@eclipse-foundation.org>

* Remove obsolete generate-yarn-sboms.yml

Signed-off-by: Lukas Puehringer <lukas.puehringer@eclipse-foundation.org>

---------

Signed-off-by: Lukas Puehringer <lukas.puehringer@eclipse-foundation.org>

URI.toURL() throws IllegalArgumentException when the URI is
syntactically valid but not absolute (e.g. a homepage/repository/
bugs/qna value missing a scheme, such as "github.com/foo/bar").
That exception was not caught, so it propagated out of
isInvalidURL() and caused a 500 Internal Server Error during
publish instead of a normal metadata validation issue.

Explicitly check URI#isAbsolute() before calling toURL(), and
also catch IllegalArgumentException defensively.

Fixes #2076