Daemon start-registration + failure-reason fixes (closes #534, #535; wolverine#3519/#3520)

[jeremydmiller]

Closes #534 and #535. Companion JasperFx.Events fixes for JasperFx/wolverine#3519 and JasperFx/wolverine#3520 — the daemon-side halves those Wolverine issues reference. The Wolverine-side change for #3520 rides on top of this (JasperFx/wolverine#3523).

#534 — StartAgentAsync(ShardName) masked the failure reason

tryStartAgentAsync swallowed a faulted start into a bool, so StartAgentAsync(ShardName) could only throw a causeless Exception("Unable to start a subscription agent for …"), filling a retrying caller's log with identical stackless stacks.

• Stash the caught start exception per shard identity (_lastStartFailures) and attach it as the inner exception when the wrapper throws; clear it on a later successful start.
• When no exception was captured (the start returned false from a non-throwing path), throw a ShardStartException whose message describes the daemon state that explains the miss — a registered-but-paused agent (with its status), high-water detection not yet running, an unknown shard, or a concurrent-start race.
• Log the two previously-silent "already running" idempotent return false paths at Debug so the "why did my start return false" trail is unbroken (the side-effect gate and catch paths already logged).
• Fix the ShardStartException message that said "stop" on a start failure.

#535 — rebuild/rewind lifecycle gaps on coordinator-less hosts

Part 2 (rewind bypasses the registry) — fixed. RewindSubscriptionAsync stopped the running continuous agents, rewound progress, then rebuilt and StartAsynced fresh continuous agents that were never registered in _agents. CurrentAgents() and StartAgentAsync(ShardName) (both read _agents) kept seeing only the pre-rewind agent that stopRunningAgents() had just HardStopped — so the shard was orphaned under Wolverine-managed distribution, and a later restart spun up a duplicate agent on the same progression row. Now each restarted agent is registered under the registry lock (registerStartedAgentAsync), making a subsequent StartAgentAsync idempotent.

Part 1 (rebuild never restarts) — documented as contract. rebuildProjection stops the continuous agents and intentionally does not restart them: a store coordinator resurrects them, and on coordinator-less hosts restoring continuous execution is the driving caller's responsibility (Wolverine's EventSubscriptionAgent.RebuildAsync, JasperFx/wolverine#3523). Restarting here unconditionally would double-start against a store coordinator, so this is a doc-note rather than a behavior change.

Tests

PerTenantStartAgentAsyncTests.rewind_leaves_the_restarted_agent_registered_and_running — starts a store-global agent, rewinds, and asserts exactly one agent is registered afterward, running, and a fresh instance (not the HardStopped pre-rewind one). Verified red before the registration fix, green after. All 240 EventTests.Daemon tests pass on net9.0 and net10.0.

🤖 Generated with Claude Code

https://claude.ai/code/session_018LDiv9GqbQkkAuU1nf4H6S

---

Related issues

• Closes JasperFxAsyncDaemon.StartAgentAsync throws a causeless 'Unable to start a subscription agent' — failed-start reasons are swallowed (startContinuousShardAsync bool ignored, silent false paths) #534
• Closes Daemon rebuild/rewind lifecycle gaps on coordinator-less hosts: rebuildProjection never restarts the continuous agents it stops; RewindSubscriptionAsync restarts agents that bypass the _agents registry #535
• Wolverine issues addressed: Managed event-subscription distribution: randomized agent fails first start on multi-(ancillary-)store Marten hosts and wedges in a permanent 30s retry loop wolverine#3519, EventSubscriptionAgent.RebuildAsync/RewindAsync leave the shard permanently stopped under Wolverine-managed distribution (daemon stops continuous agents; nothing restarts them) wolverine#3520
• Wolverine-side PR: GH-3520: EventSubscriptionAgent restores continuous execution after Rebuild/Rewind wolverine#3523