…dundant Http Sets.Routes (GH-3009) (#3010)

Two payload-shrink changes for the ServiceCapabilities snapshot:

1. EndpointDescriptor now exposes Mode and IsListener as first-class typed fields
   (alongside BrokerRole/EndpointRole/etc.), lifted from the underlying Endpoint.
   The duplicate generic OptionsDescription rows the base ctor reflects off the
   Endpoint are removed so they aren't shipped twice — CritterWatch reads these at
   the service-overview level, and Properties is becoming lazy-fetchable downstream.

2. HttpCapabilityDescriptor no longer emits the per-route "Routes" child set
   (~96 KB on a Topicus-scale graph). It was fully redundant with
   HttpGraphs[*].Chains, which the SPA already reads; the Sets collection on this
   capability had no other consumer.

Regression tests: CoreTests endpoint_descriptor_mode_tests (typed fields populated
+ no duplicate Properties rows) and Http http_capability_descriptor_tests (no
"Routes" set, core capability content intact).

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… 2.8.0 + Marten 9.4.0 (GH-3008) (#3011)

Producer side of the JasperFx descriptor cleanup (#411). That removal of
HttpChainDescriptor.Middleware / ServiceDependencies / Postprocessors (plus
MiddlewareStepDescriptor) only shipped in JasperFx 2.8.0, so this is a coordinated
critter-stack bump:
- JasperFx family 2.4.1 -> 2.8.0 (RuntimeCompiler stays on 5.x)
- Marten family 9.2.0 -> 9.4.0 (its JasperFx floor moved to 2.5.0; keeps the
  runtime gap to 2.8.0 small)
- Weasel.* 9.0.1 -> 9.0.2 (required by Marten 9.4.0)
- Polecat stays 4.2.1 (floor 2.2.0, satisfied by 2.8.0)

In HttpGraphUsageSource: stop populating the three descriptor fields and delete the
now-dead describeFrames / readServiceDependencies helpers (and the now-unused
buildChainDescriptor services parameter). The CritterWatch Pipeline tab moves to the
existing RequestHandlerSourceCode lazy fetch, which returns the actual compiled
pipeline — no operator-facing information lost.

Validated: full wolverine.slnx Release build clean (net9.0 + net10.0); CoreTests
1735, MartenTests 461, Wolverine.Http.Tests 777, PolecatTests 216 — all green.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…he send path (#3012)

Verification for CritterWatch#261 (H1): a custom IMessageSerializer attached at the
rule/endpoint level via .To(uri).DefaultSerializer(custom) must actually produce the
outgoing envelope (and therefore the wire bytes), not be silently replaced by the
global System.Text.Json default.

The existing serialization_configuration tests only assert the serializer is *attached*
to the endpoint (endpoint.DefaultSerializer.ShouldBeSameAs(...)). This adds a send-path
assertion: route a message via runtime.RoutingFor(...).RouteForSend(...) and confirm the
outgoing envelope for the overridden endpoint carries the custom serializer + content
type and that envelope.Serializer.Write(envelope) is what produces the payload — while a
sibling endpoint with no override stays on the global STJ default.

This locks in the framework guarantee analyzed for the release: the rule-level
DefaultSerializer survives Endpoint.Compile()'s `??=` global fallback and is selected by
MessageRoute on the send path. No production code change — the mechanism already works.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>