SourceGenerators: Command Router stream send capability

[Skymly]

Parent

#256

Split

#265 was the original stream umbrella. After API lock it is SourceGenerators-only. Sibling slices:

• Runtime: Runtime: Command Router stream send primitives #282
• Docs: (see Docs sibling filed with this split)

What to build

Generator support that binds [RegisterCommandHandler] types implementing IStreamCommandHandler<TCommand, TItem> into the command registry/router glue, with Verify (and/or runtime) coverage. Non-stream registry paths remain valid.

Locked decisions

• Reuse [RegisterCommandHandler] (generic + non-generic); detect stream via IStreamCommandHandler<,> contract
• Same command type cannot bind both stream and non-stream handlers (DP073 bijection)
• Contract mismatch for stream attribute without stream interface extends DP074 semantics (or reports existing DP074)
• Static / parameterless-ctor path; DI RegisterDi for stream handlers when DI flag enabled (parity with non-stream if already generated)
• No stream pipeline behaviors
• No new diagnostic ID allocation unless DP073/DP074 cannot express the case (prefer reuse)

Acceptance criteria

• [RegisterCommandHandler] on stream handlers drives generated registry/router binding for SendStreamAsync
• Non-stream generated paths unchanged for existing commands
• Verify tests: stream happy path + bijection conflict with non-stream handler on same command
• Depends on Runtime Runtime: Command Router stream send primitives #282 APIs
• No Runtime primitive definitions / Docs-only Design Doc edits in this PR

Blocked by

• Runtime: Command Router stream send primitives #282 (Runtime)

[Skymly]

Split after stream API lock: Runtime work moved to #282; Docs sibling filed; this issue is now SourceGenerators-only. Locked API: IStreamCommandHandler<TCommand,TItem>, SendStreamAsync / TrySendStreamAsync, shared 1:1 bijection, reuse [RegisterCommandHandler], no stream pipeline.