Not exactly. You're confusing the application's Faces Context with the FacesContext object. The context is pure data and you can configure JSF to either pass that data back and forth between client (browser) and server or to maintain the data on the server - one technique makes the web pages fatter and adds transmission overhead, the other replaces these problems with an increased resource load on the server. It can also make a difference if you're clustering JSF servers.
The factory uses this context as input to (re)create the JSFContext when the JSF servlet begins processing an HTTP request. The factory itself is a singleton object. As a general rule, the Factory design
pattern discourages factories from having states - they should produce a uniform product.
If you select the server-side context option for JSF, the factory isn't required to expose where it's getting the information from or even what form it's in - just be able to reconstruct the Faces context on demand.
Note also that I said intermingled non-JSF requests don't have to worry about damaging the
JSF state. The JSF state is related to JSF views and not the application in general.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.