Check the filesystem before rendering a dev 404
The router's filesystem route info is updated when the file watcher has
processed a change, so it can lag behind the filesystem when a request
arrives right after a file was written, and the request renders a 404
even though the route's file exists. Before rendering a dev 404, ask the
render server whether the request path matches a route on disk (the
development matchers re-scan the filesystem on a miss), and render the
route when it does.
Locale-prefixed API paths are rejected the same way route resolution
rejects them, and requests already invoked once are excluded so
fallback: false re-resolution still terminates.
The test makes the first-ever request for a freshly written page at
varying delays, starting at "immediately": with the write on disk, the
request must be served no matter which watchers have caught up.
