Inconsistent 5-minute bar OHLCV data between real-time and historical queries for the same bar

**Describe the bug**
5-minute bar data returned by the Historical Stock Bars API for a past date does not exactly match the data returned by the same API when called in real-time during market hours for that same bar. Specifically, the OHLCV values for the 15:50 (3:55 PM ET) 5-minute bar differ slightly between a real-time call and a subsequent historical call for the same symbol, date, and timeframe.

This suggests that bar data is being modified/finalized after it is initially served, without any documentation or versioning to indicate the data has changed.

**To Reproduce**
1. During market hours, call StockHistoricalDataClient.get_stock_bars() with TimeFrame(5, TimeFrameUnit.Minute) for a symbol (e.g., SYM, GLD) with start and end spanning the current
trading day (9:30 AM_4:00 PM ET). Record the OHLCV values for the 15:50 bar.
2. After market close (or the next day), call the exact same endpoint with the exact same parameters for the same date.
3. Compare the OHLCV values from step 1 and step 2.
Observed differences (March 4, 2026):
| Symbol │ Field │ Real-time value │ Historical value │ Delta |
│ SYM │ volume │ 638,298 │ 638,296 │ -2 │
│ GLD │ high │ 476.42 │ 476.415 │ -0.005 │
These are representative examples _ similar small discrepancies were observed across multiple symbols.

**Expected behavior**
Once a 5-minute bar's time window has closed (e.g., the 15:50 bar closes at 15:55:00), the OHLCV values returned by the API should be immutable. A historical query for that bar should return the exact same values that were served in real-time. If bars are subject to post-hoc corrections (e.g., late prints, exchange corrections), this should be documented and ideally indicated via a revision flag or timestamp.

**Screenshots**
N/A _ this is an API data consistency issue, not a UI issue.

**Desktop (please complete the following information):**
- OS: Ubuntu 22.04
- Language: Python 3.12
- SDK: alpaca-py (latest)
- API: Alpaca Data API v2, StockHistoricalDataClient

**Additional context**
If this behavior is totally unavoidable, maybe you could :
1. Document it (e.g., "bars may be adjusted for up to N minutes after close due to late prints")
2. Provide a is_final or revision field on bar responses
3. Offer a "final" feed option that waits for settlement before serving

Thanks!