Give Streamline constants and null tags on a frame without inputs while frame generation is on.

A review of the DLSS and frame generation paths against NVIDIA's guides (the DLSS programming guide 310.6.0, the
DLSS-FG guide 310.7.0, Streamline 2.14.16's guides and headers).

What follows them: the texture bias (log2(render width / output width) - 1 on top of the game's own, at each change
of the mode), the jitter (Halton, 8 x (output / render)^2 phases and 16 at least, in render pixels within half a
pixel, the scene drawn with it and the motion vectors made without it), the creation flags (HDR, vectors at the
render size, auto-exposure, depth not inverted) and the constants Streamline gets (unjittered matrices, the jitter
in pixels, the vectors' scale of one over the render size).

What did not: vk_dlssg.c holds a change of generation's state for FG_SETTLE_FRAMES frames, so for up to 12 frames
after the depth, the motion vectors or the camera went away (a menu, a fade, a load) generation stayed on and
nx2sl_frame set no constants and tagged nothing. Streamline's guide asks for the constants at every frame and for
null tags where depth or motion vectors are not valid; it logged "Unable to find 'common' constants for frame" and
"Failed to find global tag 'kBufferTypeDepth'" and used the frame before's (in every play log with frame
generation). Such a frame now gets the last frame's constants with reset set and the three tags as null. Not run in
a game yet: nx2navi_dlssg.dll builds and exports its 15 functions.

What the guides leave open: the sign of the jitter offsets against the shift of the picture, which NVIDIA says to
find by trying, and the bias reaches only the tiled, trilinear samplers, not every texture of the scene. For both
there is a test switch now, read once: NX2NAVI_DLAA_JITTER_TEST=<x>,<y> tells the upscaler the jitter times two
factors, and NX2NAVI_DLSS_LOD_BIAS_TEST=<bias> puts a bias in the rule's place. Neither was measured: the runs
that would do it start the game.

The line about the presents a second (the commit before) came at 59 a second under a limit of 60: it comes under 56
now.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>

docs/releases/v0.11.0.md

@@ -92,6 +92,11 @@ cards).
   held 2.1 GB on that card. The wait is 2 seconds at any frame rate from 15 fps up now. On our own PC at a 30 fps
   limit those textures held 209 MB on average where they held about 400. Not yet confirmed on a card that is really
   short of video memory: please report how it goes (`tex_rate_low = 0` brings the old count back).
+- **DLSS Frame Generation on frames without a scene** (the first frames of a menu, a fade or a load): generation
+  stayed on for up to 12 such frames without the camera data and the depth and motion buffers NVIDIA's library needs,
+  and the library logged errors and went on with the data of the frame before. Such a frame now tells it to start
+  anew and gives it no buffers, as NVIDIA's guide asks. Found in a review against NVIDIA's guides for DLSS and frame
+  generation, which the texture mip bias and the jitter were found to follow; not yet seen in a game by us.
 - **Crashes and hangs found in a review of the whole runtime**; none was seen in our own play, and each fix has a check
   of its own:
   - a crash when the game read memory the lazy write-back was just handing to the GPU (NVIDIA and Intel cards);