Promote AddInboxCore to public API to replace cross-assembly internals

[Vulthil]

Summary

• Remove the InternalsVisibleTo grants from Vulthil.Messaging.Inbox to its Relational and Cosmos store
  packages — internals visible across shipped assemblies is no longer allowed.
• Promote InboxCoreServiceCollectionExtensions/AddInboxCore from internal to public so the store packages
  keep working through ordinary public visibility instead. Its signature only ever exposed public types, so
  nothing else needed to change. Documented it as a first-class extension point: a custom IIdempotencyStore
  package registers its own store and then calls AddInboxCore to get the same retention sweep, metrics, and
  TimeProvider wiring the first-party Relational/Cosmos stores get, and states the configure delegate's
  invocation contract (once eagerly for the gates, once deferred for injected consumers).
• Add direct test coverage for AddInboxCore proving third-party-style usage (a store registered ahead of
  the call resolves unchanged) alongside the retention/metrics/TimeProvider wiring assertions already used
  for AddRelationalInbox.
• Add a "Custom stores" section to the inbox pattern doc showing the registration pattern.

Verification

• Full solution build: clean, 0 warnings/errors.
• Vulthil.Messaging.Inbox.Tests: 29/29 (both target frameworks).
• Vulthil.Messaging.Inbox.Relational.Tests: 14/14 (both target frameworks), unmodified — the store
  extension's observable behavior is unchanged; this is a visibility promotion, not a behavior change.
• dotnet pack -c Release (fresh obj/bin) for Vulthil.Messaging.Inbox, Vulthil.Messaging.Inbox.Relational,
  and Vulthil.Messaging.Inbox.Cosmos: APICompat reports no breaking changes for all three, no compatibility
  suppressions needed.
• grep -r InternalsVisibleTo src/ shows no production-to-production grants anywhere in the repo.

Backport to v1.0: no — additive public API ships with the next minor.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.