ApplyView::read() doesn't go through the apply-state-table cache like peek() does

[mvadari]

ApplyViewBase::read() (ApplyViewBase.cpp:61) calls items_.read(), not items_.peek(). peek() installs the view's own cached copy of an SLE; read() does not. So a read() and a peek() for the same key on the same ApplyView can return two different SLE objects — if code modifies the one from peek(), the one returned earlier by read() goes stale.

Found while reviewing PR #7886, which works around this in SLEBase's resolveEntry() helper by routing read-only lookups through peek() via a dynamic_cast<ApplyView*> check instead of calling read() directly.