Re: the timeout exception.
This is a known bug in WF4. It is the result from the fact that the WF/WCF infrastructure will try to deliver a message. That means that it will hang on to the message for a bit and see if the workflow gets to a state where it can process the message. The infrastructure doesn't really know about the structure of your workflow. So even while you are fully aware that the workflow is in a state that it will never be a able to process the message given the current state the infrastructure will wait.
Re: Avoiding PageA being shown.
This is really up to the UI layer and outside of the scope of the workflow. And as you pointed out not completely avoidable. However I have had good success with using the bookmark information in the persistence store. Each Receive activity creates a bookmark with a known name and I basically checked for the bookmarks in there. Based on this information I would enable/disable parts of the UI. It will not really solve the problem of a user opening a page and leaving it like that for 15 minutes so you still need an error handler when you call the service method. One way of improving on that is, assuming an HTML bases UI for a moment, to use WebSockets, or SignalR to be more practical, and push workflow state changes from the server to the client. Still won't eliminate the need for error handling but should make the window with UI in the wrong state much smaller.