AppFlowContextFactory should give delegate its own context to destroy.

It seems reasonable for a ScreenContextFactory to assume that the context instance that it returned from createContext is the one that it will receive in destroyContext. Certainly that's what I'd expect, principle of least astonishment and all that.

AppFlowContextFactory violates this trust. It receives a Context from its delegate's create method, then gives it some other context to destroy. In order for the delegate to do its own fishing it has to know somehow that it's okay to cast the given Context to a ContextWarpper and trust that the context it actually understands is in the getBaseContext() chain. 

On the other hand, if AppFlowContextFactory gets to assume that it's receiving a Context that it created in its destroy method, the cast and getBaseContext() call are perfectly reasonable. It used a package private method on AppFlow to create the thing in the first place, it should know exactly how it's structured.