fix(ide-workspace): mark the registry mutation at the publisher, not at a URL (#6654)

[delchev]

Fixes #6654. Follow-up to #6641, which closed one instance of this race and left a second one open.

Why it survived #6641

#6641 taught SynchronizationProcessor to defer artefact cleanup while the registry is half-written, and JavaSynchronizer not to compile a batch it knows is incomplete. Both ask RegistryMutationTracker — but the tracker was fed only by a servlet filter mapped on /services/ide/publisher/** and the workspace endpoints. Every other publish path stayed invisible, and the most frequent publisher in practice is not that endpoint:

// components/ui/service-generate/.../generate.mjs
lifecycle.publish(user.getName(), workspace, project);        // line 107
lifecycle.unpublish(projectName + "/gen/" + genFolderName);   // line 195

Served from /services/js/..., so the filter never runs.

What that cost

From PR #6644's smoke leg — a build that already contained #6641 (verified: b5021cf is an ancestor of the run's head):

09:06:13.905  POST /services/js/service-generate/generate.mjs/...      <- not the publisher endpoint
09:06:14.783  PublisherService - Unpublished ...                        <- hole opens
09:06:15.372  JavaSynchronizer - Removing Java artefact
              [/retire-owner/gen/invoices/api/invoice/InvoiceController.java] - its source is gone  (x6)
09:06:15.463  PublisherService - Published ...                          <- hole closes, 680 ms later
09:06:20.619  Compiled batch: [12] units, [0] class file(s); [12] failed
              (cannot find symbol: class InvoiceRepository)

Client Java compiles all-or-nothing, so zero class files, no controllers registered, and IntentCrossModelFieldRetirementIT's 60 s poll saw only 404s. That was the last batch of the run — nothing repaired it. The same window is the likeliest explanation for IntentEmissionCoverageIT reading "Status": null two seconds after a republish on #6647's leg.

The fix

PublisherService brackets its own writes with enter() / exit(). Every caller is then covered by construction — the HTTP endpoint, the JS lifecycle API, generated client Java, tests. Enumerating callers was the bug; the service is the one place they all funnel through. The tracker's javadoc now states this, so the next publish path brackets its write instead of adding a mapping.

The bracket sits on publishResource / unpublishResource — the methods that actually touch the repository — so a disabled publish or a no-op path does not register a phantom mutation.

I deliberately left RegistryMutationFilter in place: it is now redundant for the publisher endpoint, and its workspace mapping was never about the registry, but removing it is a behaviour change beyond this bug. Worth a separate look.

Verification

• SynchronizerCleanupRaceIT gains a contract test: a publish that never touches the HTTP layer must still register as a completed registry mutation, because that count is exactly what the pass compares. Verified red-first — stashed the fix, reinstalled, and it fails precisely at that assertion; restored, and both tests pass (30 s).
• IntentCrossModelFieldRetirementIT — the IT this race broke — green locally.
• 34 unit tests across core-base / core-initializers / ide-workspace green; formatter:validate and the release-profile javadoc clean.

Not claimed: neither CI failure was ever locally reproducible, so this fixes the mechanism the logs show rather than reproducing those two runs. The secondary point in #6654 stands separately — a batch that compiles to zero class files is not necessarily retried, so a missed hole is still a permanent outage rather than a transient one.

🤖 Generated with Claude Code