GH-4073: refuse the agent/sender mismatch at bootstrap, plus the gates and tests #4070 left open

[jeremydmiller]

Follow-up to #4070, which fixed this regression independently and landed first.

We reached the same design — an Endpoint.SendsInline predicate replacing the Mode == EndpointMode.Inline literal — so everything this branch had in common with #4070 has been dropped in favor of main's version. What is left is the delta #4070 does not cover.

One thing worth flagging from the merge: Endpoint.SendsInline auto-merged into two declarations of the same property. We added it in different places, so there was no textual conflict for git to report, and the result would not have compiled. Resolved by keeping main's declaration.

1. The bootstrap guard (the substantive part)

Main still registers the callback under a single &&:

if (sender is ISenderRequiresCallback senderRequiringCallback && agent is ISenderCallback callbackAgent)
{
    senderRequiringCallback.RegisterCallback(callbackAgent);
}

When the second half is false the registration is silently skipped. #4070 removed the current way of reaching that state, but not the state itself — any future transport that gates its sender wrongly lands right back in it.

That matters because of how the failure presents. BatchedSender.SendAsync posts to a block and returns, so the throw lands on a worker thread nothing awaits; the block logs it and the caller sees only messages that never arrive. The observable symptom is a ~30s TimeoutException far from the endpoint at fault, which on a broker-backed suite reads as flakiness. Measured on the Redis suite: 2m39s to a timeout naming nothing, versus 147ms to a bootstrap error naming the endpoint, both types, and the fix.

The invariant is total, which is what makes this safe to enforce: BatchedSender is the only ISenderRequiresCallback in the codebase and SendingAgent the only ISenderCallback, so a callback-requiring sender under an inline agent is always a transport bug.

2. The two gates #4070 missed

PubsubEndpoint.CreateSender and HttpEndpoint.CreateSender are still on the literal. Inert today — neither sets supportsNativeAck — but they are the last two.

Deliberately left alone, because they are not sender gates: PubsubEndpoint.buildListener and SqsListener's ExtendVisibilityWhileHandling check (both listening-side, where SendsInline is the wrong question) and Endpoint.ModeIgnoresParallelism (execution block, not sending). TCP is exempt entirely — supportsMode refuses Inline, so it never gets an inline agent.

3. Regression tests

#4070 shipped none, so nothing currently pins this behavior.

• native_ack_sender_pairing_is_validated (3, CoreTests) — the mismatch is refused at bootstrap; the same sender is fine under a buffered agent; SendsInline covers both inline-producing modes.
• the_outgoing_side_of_a_native_ack_stream_sends_inline (Redis) — asserts the agent/sender pairing directly, in milliseconds, rather than through a delivery that takes 30s to time out.
• a_native_ack_stream_actually_delivers_what_is_sent_to_it (Redis) — the end-to-end path.

Verification

• dotnet build wolverine.slnx -c Release -f net9.0 — clean, 0 warnings
• CoreTests native-ack classes 15/15
• Redis native_ack_mode 8/8

Full CI was green (39/39) on the pre-merge head; re-running against main.