Fix #4788 — repopulate mt_natural_key on projection rebuild (supersedes #4789)

[jeremydmiller]

Supersedes #4789 (test contribution from @ytqsl preserved as the first three commits on this branch — same author, same email — followed by the implementation commit).

Root cause

NaturalKeyProjection (auto-registered for any aggregate carrying [NaturalKey]) maintains the mt_natural_key_{aggregate} lookup table from an inline ApplyAsync that iterates the StreamActions queued during the current SaveChanges and emits ON CONFLICT upserts per matching event.

That dispatch fires correctly on the normal append path, but the async-daemon rebuild path appends no streams — it replays already-persisted events from mt_events through the projection's aggregator and stores the rebuilt snapshots, so the inline projection chain is never given anything to iterate. Net effect: after RebuildProjectionAsync, the parent projection's documents are repopulated but the mt_natural_key table stays exactly as teardown left it (empty), and any subsequent FetchLatest<T, TNaturalKey> misses.

The PR description on #4789 said "expect the root cause and fix to land in JasperFx.Events" — after walking the dispatch chain I went a different way. JasperFx already exposes everything Marten needs:

JasperFx surface	What Marten uses it for
IAggregateProjection.NaturalKeyDefinition	Detect that a source projection has a natural key
EventRange.Events on every rebuild page	The exact events to re-emit upserts for
ProjectionBatch.SessionForTenant(tenantId) returning a ProjectionDocumentSession whose ISessionWorkTracker IS the ProjectionUpdateBatch	Route ad-hoc SQL so it flushes inside the same rebuild transaction

So this PR is Marten-only — no JasperFx changes needed. If you'd prefer the fix to live further upstream I'm happy to redo it, but I wanted to flag that the existing abstractions covered the case cleanly.

Changes

Two new hooks in Marten plus a small refactor:

1. teardownProjectionStorage — when the source projection carries a NaturalKeyDefinition, also queue a DELETE FROM mt_natural_key_X so the rebuild starts from a clean slate (mirrors the doc-table teardown).
2. StartProjectionBatchAsync — in ShardExecutionMode.Rebuild, look up the source by range.ShardName.Name, and when it has a NaturalKeyDefinition feed range.Events through a new NaturalKeyProjection.QueueUpsertsForEvents method (per tenant). Operations routed through projectionBatch.SessionForTenant(...) so the upsert SQL flushes alongside the rebuilt snapshots in the same batch transaction — not on the bare session's unit-of-work, which ProjectionBatch.ExecuteAsync never touches.
3. NaturalKeyProjection — extracted the upsert SQL builder to take (streamId, streamKey, tenantId, innerValue) instead of a StreamAction, so the inline path (StreamAction-driven) and the rebuild path (IEvent-driven) share the SQL. ApplyAsync behavior is byte-for-byte unchanged.

Test plan

• @ytqsl's Bug_4788_natrual_key_table_not_populated_on_rebuild (commits 27ecadda6 / 12f16dbef / 6322a6353 on this branch) — was red on master, now green.
• Regression sweep on net10, all green:
  • 34 / 34 existing natural-key tests (FetchForWriting/*natural*, Bug_4197, Bug_4199, conjoined + archived suites)
  • 8 / 8 EventSourcingTests rebuild tests
  • 31 / 31 DaemonTests rebuild tests

Closes #4788