I'd say you need to determine what the threshold is for when the page of interest needs to be refreshed; I don't think it's as simple as a Boolean. A user could suspend and pretty much immediately resume (say within 15 seconds) and that may not merit a refresh, but that same user could also linger on secondary page, never suspend, and come back to a page 30 minutes later, in which case the page data could be quite stale. Your Boolean may need to be more of a timestamp.
That said, the Resuming event does not fire OnNavigatedTo. If you need to know what page you're coming back to, you'd need to save that info when you suspend, perhaps in LocalSettings. But now consider that if you're using SuspensionManager in C#/XAML, that is already happening on your behalf, and if you think about it, the behavior you want is not too different (if at all) from what should occur when the application comes back from a terminated state.
So in a similar fashion, you could add a call
await SuspensionManager.RestoreAsync()
as your implementation of the Resuming event. That would, in turn, cause an OnNavigatedTo and you'd run through the normal logic of bringing up that page.
It's technically not resuming anymore, you're just using the resuming event to trigger the reload of the entire page. That could be overkill depending on the nature of the page (e.g., maybe there's a lot of semi-static data and only a tiny bit of volatile data - resuming doesn't need to restore the static data). You may want to dial back how much is refreshed on a 'resume' versus a 'terminate,' but since SuspensionManager is code you can see and change, so you can control that level of granularity. And maybe it's here that you introduce you're idea of the Boolean to differentiate what needs to be done in LoadStateAsync when it's invoked by Resuming versus by other means.