TFDMemTable shows stale rows after external edits to a joined TFDQuery's source tables

Goal: establish when FireDAC invalidates the in-memory buffer of a TFDMemTable populated from a TFDQuery whose SELECT joins several tables, in a Delphi 12 multi-user application. Exact refresh semantics are assumed similar across recent FireDAC releases, but they need checking against the installed version.

TFDMemTable is a disconnected in-memory dataset, so INSERT, UPDATE or DELETE activity from other sessions is invisible to it until something re-reads the source. FireDAC documents Refresh and UpdateOptions.RefreshMode for re-reading posted rows, but neither is clearly specified for rows changed externally between fetches, particularly with joined queries. CachedUpdates on the source query adds an unapplied delta that any reload must coexist with.

The unresolved point is which mechanism is the supported refresh path for this setup, and what each option costs:

• Does TFDQuery.Refresh re-execute a joined SELECT, and when the MemTable was filled via CopyDataSet, is a second copy the only way new rows appear?
• Does FireDAC offer a documented notification or polling facility for external modifications, or is scheduled re-fetching the expected design?
• How can unapplied CachedUpdates deltas and the current cursor position survive a reload without lost or duplicated edits?