Upgrade JasperFx to 2.39.5

[jeremydmiller]

Bumps JasperFx, JasperFx.Events, JasperFx.Events.SourceGenerator and JasperFx.SourceGenerator from 2.37.0 to 2.39.5. JasperFx.RuntimeCompiler stays on its own 5.x line.

Why now

The headline is JasperFx/jasperfx#632, which fixes the Count accounting Wolverine's back-pressure reads:

PushUpstream built its BlockSet with an empty previous list, so the downstream block — the one actually executing the work — was invisible to the set. Count double-counted the top transform stage and reported zero for any backlog sitting downstream, and WaitForCompletionAsync returned after draining only the top stage.

ShardedExecutionBlock.DeserializeFirst composes exactly that shape, for both BufferedReceiver and DurableReceiver. So a PartitionProcessingByGroupId endpoint latched back-pressure against the wrong number and then decided whether to resume against that same wrong number — the sharded slots can hold thousands of messages the limits never see.

This is the companion to #3831 (merged): that PR made a latched listener say so, this one makes the number it says correct. Both come out of the permanently-latched console ingest listener at CritterWatch#922.

Also in the 2.37.0..2.39.5 range:

• MQTT topic rules publishing #600 / ISendMyself implementation for broadcasting to a topic #601 — the app-assembly stack walk could adopt a test runner. CallingAssembly.Find() rendered the stack as text and guessed each frame's assembly by trying to Assembly.Load progressively shorter dotted prefixes, which resolved NUnit's nunit.framework exactly and missed xUnit's xunit.v3.core entirely. This is the JasperFx side of CIPolecat red on main since 1dfdd42a1: bisected to a version-string bump, mechanism unknown #3776/Never adopt a test-runner assembly as the application assembly (GH-3776) #3777. (The GH-3521 application-assembly warning has a hole on one path and fires on healthy hosts on the other #3778, the Wolverine-side twin, is untouched and stays open.)
• Conventional configuration of Kafka endpoints #599 — DatabaseId's escaping now survives a System.Uri round trip.
• Support file uploads #618/Add wildcard routing support. #619/Reorder attribute application in HttpChain #621/QUESTION: Scalability - Multiple instances #622/Explicit documentation on registering http middleware #626/Tweaks test to better test if IEvent is handled #631 — per-tenant projection progression fixes, and a per-shard heartbeat nobody read is no longer written.

Verification

check	result
dotnet build wolverine.slnx -c Release	0 warnings, 0 errors
CoreTests net9.0	2248 / 0
CoreTests net10.0	2247 / 0 (pre-rebase; +1 is #3831's new test)
MartenTests.concurrency_resilient_sharded_processing	4 / 4

I confirmed the restore genuinely resolved 2.39.5 rather than reporting a green build off a stale graph — 336 targets on 2.39.5, package present in the local cache.

Four projects still showed 2.37.0 in stale project.assets.json files. All four are <Build Project="false" /> in wolverine.slnx, so the solution build never touches them. I built them directly anyway, because CIHttpAspVersioning runs one of them in CI:

• Wolverine.Http.AspVersioning.Tests — clean.
• PolecatIncidentService.Tests — 13 analyzer errors (xUnit1051, VSTHRD103). Pre-existing: I re-ran it against 2.37.0 and got the identical 13, so it is unrelated to this bump. That sample is rotting quietly behind its Build=false flag and deserves its own issue.

Not in scope

Marten stays at 9.22.2. Marten 9.22.4 is the release built against JasperFx 2.39.3, but it also floors Weasel.Postgresql/Weasel.Storage at 9.23.2 while Wolverine directly pins Weasel at 9.23.0 — an NU1605 downgrade that drags a seven-package Weasel bump along with it. Marten 9.22.2's JasperFx floor of 2.37.0 is satisfied by 2.39.5, so the unification is legal as-is. Separate PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WHAuhdWS3XeAk16swV9G8m