Freeze MessageMappingRegistry.ModuleKey at construction

[VDBBjorn]

Closes #154

In a sharded module, WithOutbox built one MessageMappingRegistry eagerly — before any Register callback ran — then registered a callback that assigned registry.ModuleKey = context.ModuleKey. RegisterModule runs that callback list once per shard, over the same object:

1. shard db1's callback sets ModuleKey = "orders#db1"
2. shard db2's callback sets ModuleKey = "orders#db2" ← overwrites

Every shard's OutboxHandler held a reference to that one registry, so after registration it read "orders#db2" no matter which handler asked. Every mapper in every shard resolved GetKeyedService<EventSerializer>("orders#db2"); the first shard's keyed serializer was never reached and its upcaster chain was silently bypassed.

The failure mode splits on schema version. An event stored at an old version trips the EV-1 guard in DeserializeEvent and throws InvalidOperationException on the first shard's outbox entries. An event at the current version deserializes cleanly under the wrong serializer and no one finds out — a silent data-integrity defect.

What changed

The mutability that made last-write-wins expressible is gone, rather than being guarded against.

• IMessageMappingRegistry.ModuleKey — setter removed, get-only.
• MessageMappingRegistry — default constructor replaced with MessageMappingRegistry(string? moduleKey); the key is now fixed at construction. Null stays legitimate for an unsharded module that has no module key.
• WithOutbox — registry construction and configuration moved inside the Register callback, so each shard builds its own. The handler registered for "orders#db1" holds a registry whose key is immutably "orders#db1".
• PublicAPI.Unshipped.txt (Alberto.Messaging) — three *REMOVED* entries for the setter and default constructor, plus the new constructor.

Tests

WithOutbox_in_sharded_module_each_shard_resolves_its_own_keyed_serializer is the regression test. It drives the deferred registrations for two shards directly — no Postgres, no full AddAlberto — so it stays in the fast suite. It asserts configureMappings runs once per shard, that each registry carries its own shard key, and that each resolves its own shard-keyed EventSerializer, delivering the shard-specific upcasted value.

The existing single-module positive test was kept and renamed to Map_WithMessageType_ResolvesModuleKeyedSerializerSoUpcasterChainFires. Its doc comment previously narrated a "before the fix" break that never happened — the single-module case worked in production; the defect was specific to sharding. That narration is corrected rather than preserved.

Verified by breaking

Against origin/main's production code the regression test fails:

Assert.Equal() Failure: Values differ
Expected: 2
Actual:   1

The 1 is the diagnostic: configureMappings ran once, eagerly, producing the single shared registry both shards then mutated. With the fix it runs once per shard and the test passes.

Full fast suite on the rebased branch: 1611 passed, 3 skipped, 0 failed. Release build: 0 errors.

[VDBBjorn]

CI note: the red Changed code here is a cancellation, not a score failure — the job conclusion is cancelled (25m51s, no report artifact, no score line).

The same tree passed this gate before the rebase: run 31124238686 on a130347a reported Changed code: success. The rebase onto dd58502 was needed only because main moved under the strict status-check policy; the diff is unchanged.

Merging on the two required contexts, build-test and pr-policy, both green. The mutation gate is not a required context. The underlying instability is tracked in #167.