Add registered event source and stream definitions

[einari]

Event sources and streams can now be registered with the Kernel and used when appending. Existing appends, options and event contexts are unchanged.

Added

• @eventSource({ name?, description?, concurrency? }) and repeatable @eventStream(name, { description?, concurrency? }) definitions, plus ConcurrencyDimensions. Definitions are discovered and registered with the Kernel at startup, right after event types. Duplicate source or stream names are rejected. (part of Registered event source definitions and streams: client parity #228)
• AppendOptions.eventSource / eventStream and the same per-event fields on EventForEventSourceId for append and appendMany, including mixed-source batches. The wire EventSource key and routing are set from the definition; unknown sources, undeclared streams, a stream without a source and contradicting explicit routing fail before anything is sent. (part of Registered event source definitions and streams: client parity #228)
• When no explicit concurrency scope is given, a definition's concurrency dimensions (a stream's, when it declares any) derive the scope; explicit scopes always win. Within appendMany and a committing unit of work, one event source id that needs differing guards (for example two stream ids) is rejected before anything is written, because the Kernel accepts one scope per event source id; pass an explicit shared concurrencyScopes entry or split the batch. Tracked in core as Reject incompatible definition-derived guards in same-id batches Chronicle#4545. (part of Registered event source definitions and streams: client parity #228)
• EventContext.eventSource on reads, reactor and reducer deliveries; undefined for events appended without a definition. IEventStore.eventSources exposes the discovered definitions. (part of Registered event source definitions and streams: client parity #228)
• Documentation: Event sources and streams. (part of Registered event source definitions and streams: client parity #228)

Changed

• Requires @cratis/chronicle.contracts 19.30.0 and a Chronicle 19.30.0 Kernel to use event sources.

[cratis-direct]

The "Projection oracle" CI failure on this PR (the fixture version/hash mismatch reported at run 37099328763) was caused by Tools/ProjectionOracle/ProjectionOracle.csproj's ChronicleVersion/Cratis.Arc pins not following the @cratis/chronicle.contracts bump to 19.30.0 in a0b7b92, plus the packaged client's CausationManager wrapping each ambient Causation in a new private Entry type (breaking the oracle's reflection-based causation push). Commit 1e015fd already fixes both — confirmed yarn oracle:check (91/91 fixtures) and yarn workspace @cratis/chronicle test (3113 tests) both pass clean on this branch now, and CI (check job) is green.

One thing worth a second pair of eyes while re-verifying: 1e015fd also updates ProjectionReadModelProcessor.ts and children-identified-removed.json to follow a real Chronicle kernel behavior change — a read-model document created only from child events (no root From) no longer transitions __initialized to true on a later child-only event. I bisected this independently while working the same CI failure: it's present from Chronicle 19.28.0 onward and absent in 19.27.0, with no mention in the 19.27.0–19.30.0 release notes. I filed Cratis/Chronicle#4544 to get the Chronicle team to confirm whether it's intentional, since right now there's nothing marking it as a tracked kernel question (the other kernel quirks in this oracle's README link an issue). Worth linking that issue from the fixture/README once triaged, in case the kernel team comes back and says it was unintentional.

[einari]

Scope-guard fix pushed: batches needing differing concurrency guards for one event source id now fail before any write (client, and unit-of-work preflight). Verified: 3120 unit specs, build, standard-types, native, snippets, kernel integration on isolated 18700 (jobs flake once on cold start, passes on rerun). Core tracking: Cratis/Chronicle#4545.