CommandProcessor.Call: "No Subscription registered fpr replies of type" — typo, and it names the wrong type

`src/Paramore.Brighter/CommandProcessor.cs:1429`:

```csharp
var subscription = _replySubscriptions?.FirstOrDefault(s => s.RequestType == typeof(TResponse));

if (subscription is null)
throw new InvalidOperationException($"No Subscription registered fpr replies of type {typeof(T)}");
```

Two things:

1. **`fpr`** should be `for`.
2. **It prints `typeof(T)`, but the match is against `typeof(TResponse)`.** So the message names the request type while the lookup that failed used the response type — a reader is told to register a subscription for the wrong thing.

This is the first guard on the `Call` path, six lines before the `_responseChannelFactory` check, so it is the message anyone with no RPC wiring actually sees.

Suggested:

```csharp
throw new InvalidOperationException($"No Subscription registered for replies of type {typeof(TResponse)}");
```

Found while documenting `Call`'s failure modes for the Brighter guide — the documentation originally named the *other* exception, because the second guard is the one that mentions what you skipped. The maintainer asked for this to be filed.

Open src/Paramore.Brighter/CommandProcessor.cs at line 1429 and inspect the missing-subscription guard in the Call path. Confirm the exception message uses “for” and identifies the response type matched by the subscription lookup; done means the typo and misleading type name are corrected without changing the surrounding guards.

Written by the indexing model from the issue text.