MsSqlMessageQueue.NumberOfMessageReady interpolates the topic into SQL while its neighbours parameterize

`src/Paramore.Brighter.MessagingGateway.MsSql/SqlQueues/MsSqlMessageQueue.cs:169`:

```csharp
var sql = $"select COUNT(*) from [{_configuration.QueueStoreTable}] where Topic='{topic}'";
```

The neighbouring statements do it properly:

```csharp
// :215
"set nocount on;insert into [...] (Topic, MessageType, Payload) values(@topic, @messageType, @payload);"

// :236
"set nocount on;with cte as (select top(1) Payload, MessageType, Topic, Id from [...]" // @topic bound below
```

So the file already knows how; `:169` is the odd one out.

### Risk

**Low, and worth saying so plainly.** Topics are developer-configured rather than user input, so this is not a live injection path in any normal deployment. But `NumberOfMessageReady` is **public**, a topic is a string a caller can pass, and the asymmetry with `:215`/`:236` means the next person to read this file has to work out whether the difference is deliberate.

### Suggested fix

Bind `@topic` as the two statements below it already do.

Found by review 18 on #4331.

Start in src/Paramore.Brighter.MessagingGateway.MsSql/SqlQueues/MsSqlMessageQueue.cs at NumberOfMessageReady around line 169, then compare it with the parameterized statements around lines 215 and 236. Bind the topic as @topic in the count query, and confirm that the resulting statement matches the neighboring parameterized pattern.

Written by the indexing model from the issue text.