Two sites hard-code the default CloudEvents source instead of MessageHeader.DefaultSource

## Summary

`MessageHeader.DefaultSource` exists as the canonical constant for the default CloudEvents source, but
two sites still hard-code its value as a string literal. They agree with the constant today by
coincidence, not by construction.

## The sites

- `src/Paramore.Brighter/Publication.cs:64`
```csharp
public Uri Source { get; set; } = new Uri("http://goparamore.io");
```
- `src/Paramore.Brighter.MessagingGateway.Kafka/KafkaMessageCreator.cs:372`
```csharp
? new HeaderResult(dataSchema, true)
: new HeaderResult(new Uri("http://goparamore.io"), true));
```

Everywhere else uses the constant: `RmqMessageCreator.cs:331`, `RedisMessageCreator.cs:331`,
`SqsInlineMessageCreator.cs:293`, `RocketMessageConsumer.cs:452`, `RelationDatabaseOutbox.cs:1914`,
`JustSayingTransform.cs:248`, and — as of #4311 — `AzureServiceBusMessageCreator`.

## Why it matters

`JustSayingTransform.cs:256` decides behaviour by comparing against the constant:

```csharp
if (message.Header.Source != s_defaultSource)
```

That comparison only does the right thing for a message whose source came from one of the literal
sites because the two strings happen to be identical. Change `MessageHeader.DefaultSource` and the
literals silently stop matching — the comparison keeps compiling and quietly changes behaviour. The
literals are load-bearing without declaring it.

`Publication.cs:64` is the more significant of the two, since it seeds the default source for every
publication that does not set one explicitly.

## Suggested fix

Replace both with `new Uri(MessageHeader.DefaultSource)`. No behaviour change — the values are
byte-identical today; this makes them identical by construction instead of by coincidence.

Raised out of the review on #4311, which made the same substitution in the Azure Service Bus gateway.