StreamHub: standalone BarHub silently drops before-head bars

[DaveSkender]

Problem

src/_common/Bars/Bar.StreamHub.cs:90 (now under src/Common/) returns early when item.Timestamp < Cache[0].Timestamp, with no exception, notification, or status. This is a silent data-loss path.

Empirically confirmed on out-of-order input, two-feed-merge, and backfill patterns during the pre-v3.0 confidence review (overall-review-v3 swarm, 2026-05-29).

Proposal

Surface the drop instead of silently discarding it — options:

• A status/return value indicating the item was rejected
• Route through OnError
• A dedicated dropped-bar callback/event

Also document the before-head policy on IStreamHub.Add.

History

• Originally tracked as SR001 in docs/plans/streaming-indicators.plan.md (now removed; see git history for the full write-up).
• Reviewed 2026-05-30 and initially deferred, then reopened 2026-05-31 per maintainer quality steer: "silent data loss is the canonical obvious problem" for a v3.0 streaming debut. Ultimately shipped v3.0 with the limitation undocumented-turned-tracked here rather than blocking the stable tag.
• Related: the general prune-stable rollback gap is a separate, larger issue — see the framework state snapshot/restore work this pairs with.