tests: nothing asserts that a gateway ChannelFactory rejects a non-matching Subscription

Companion to #4334, which proposes the *fix*. This is the *pin*.

Every gateway `ChannelFactory` downcasts its `Subscription` and throws `ConfigurationException` when the cast fails — MSSQL at `ChannelFactory.cs:46`, `:66`, `:88`, and the other transports likewise. **No test asserts it.** `tests/Paramore.Brighter.MSSQL.Tests/MessagingGateway/` covers scheduler forwarding and requeue, and nothing covers the constraint.

That constraint cost two sample applications in this repository their ability to start (#4331), and the behaviour is currently documented in a code comment and a documentation page rather than pinned by anything executable.

Suggested, per transport or once over a table of them:

```csharp
[Fact]
public void When_creating_a_channel_with_a_non_mssql_subscription()
{
var factory = new ChannelFactory(new MsSqlMessageConsumerFactory(configuration));

var ex = Assert.Throws(() =>
factory.CreateSyncChannel(new Subscription(...)));

Assert.Contains("MsSqlSubscription", ex.Message);
}
```

It needs no broker and no database — constructing the factory and calling the method is enough; I ran exactly that shape while investigating, with an `MsSqlSubscription` as the control to prove the assertion discriminates.

Per `CLAUDE.md` this belongs behind `/test-first`. If #4334 lands, this test moves up to the validation spec instead of the factory.

Start in tests/Paramore.Brighter.MSSQL.Tests/MessagingGateway/ and inspect the gateway tests, then read the MSSQL ChannelFactory.cs locations at lines 46, 66, and 88. Add coverage for creating a channel with a non-MSSQL subscription, using the existing factory and no broker or database; done means the test verifies ConfigurationException and identifies the expected subscription type.

Written by the indexing model from the issue text.