JasperFx 2.69.1

Two fixes on top of 2.69.0.

#829 — a View slice's ConsumedEvents carried Archived and Compacted<T>

Found while wiring ProjectionEventModelSource into Fisher. JasperFxSingleStreamProjectionBase.determineEventTypes() concatenates both stream lifecycle events onto every non-empty apply set, so an aggregate declaring exactly two Apply methods yielded a View slice consuming four event types. Honest about what the projection handles; not what an Event Model canvas means by the events a read model consumes — they render as stickies for events the application never wrote and no command slice emits, so they link to nothing.

Filtered in ProjectionEventModelSource.ToSlice, and deliberately not in the reader that fills AppliedEvents: Compacted<T> is a real stored event, the same reader feeds AggregateDescriptor.AppliedEvents, and a monitoring console asking "what does this projection handle" wants both. The narrow question is the canvas one, so the judgement sits with the thing drawing it. SubscriptionDescriptor.AppliedEvents is unchanged.

Matched on type identity — typeof(Archived).Assembly and typeof(Compacted<>).Name — so an application type called Archived keeps its sticky, and a rename upstream cannot leave a stale string behind.

Downstream: Fisher's event_model_source.a_registered_projection_becomes_a_view_slice asserts Archived is present, so that test moves when Fisher takes this version (JasperFx/fisher#251).

#827 — no subscription could start on the hosted daemon path, on any store

JasperFxSubscriptionBase's ILoggerFactory BuildExecution overload handed SubscriptionExecution<T> the database where its sibling hands the store — and the store is what implements ISubscriptionRunner<T>. That overload threw on construction, unconditionally.

JasperFxAsyncDaemon.buildAgentForShard picks it whenever the daemon was built with a logger factory — the hosted / projection-coordinator path — so on Marten, Polecat and Fisher alike a subscription registered that way never ran. It surfaced as a logged shard start failure rather than a crash: the app came up and the subscription silently did nothing.

Every other ISubscriptionFactory in the tree already passed store from both overloads; this one was the lone outlier.