Count the texture cache's short waits in seconds below 60 presents a second too.

The cache counts its short waits in presents (PRESENTS(n): n presents at 60 a second) and scales them by the presents
a second. Above 60 it always did. Below 60 the rate stopped at 60, so the 120 presents a released texture stays out
of the VRAM pressure's reach (STALE_FRAMES) were 4 s at 30 presents a second and 5.7 s at 21. The game lets go of
textures by the second, as the player moves, so what that window holds grows with its length.

A tester's log (RTX 4070 SUPER, 2560x1440, DLSS Quality with frame generation, texture detail Full, 0.10.2-rc4): the
card went to 11,198 MiB against a budget of 10,600 while the frame rate fell from 63 to 21 fps. The released textures
held 2,644 MiB against their bound of 384, and 2,105 MiB of that was released too lately to go (442 MiB when the
pressure began).

On an RTX 5090 with the budget taken as 10,600 MiB and the tester's output settings, a walk through Hyrule Field at a
30 fps limit: the released-too-lately textures were all in their first 120 presents (the new census line below) and
held 383 and 429 MiB on average at the memory reports of two runs, against 292 MiB at 60 fps. With this change they
are in their first 60 presents and hold 209 MiB. Textures made again after a drop: 295 and 523 before, 511 after.
Not shown: the tester's 21 fps and a card that is really over its budget, which this card does not reach; the memory
in use as the driver counts it stayed at 9.8 GiB in the capped runs.

The rate now follows the presents down to 15 a second (vk_tex_release.h trl_rate_sample, trl_rate, trl_presents),
once eight seconds in a row were under 60, and never in a run's first eight seconds; one slow second among fast ones
still shortens nothing. Every wait PRESENTS counts follows it. NX2NAVI_TEX_RATE_LOW=0 stops the rate at 60 as before,
and one line says when the rate crosses 60. Values at 60 presents a second and above are the ones before.

The census of the released textures over their bound gets a second line: what the ones released too lately wait for
(their first presents after the release, content only the GPU made, the gap before a take-back with or without a
lookup still reaching them). It is what showed which wait held the memory.

tests/tex_release_check has the rate's checks and a table of the wait by presents a second; they fail against the
rule before.

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

docs/releases/v0.11.0.md

@@ -85,6 +85,13 @@ cards).
   it was found in): the first memory report asked Windows for a summary of the game's heap, and that summary holds
   every allocation of the game while it is taken. It is now taken before play only (`mem_census = 1` asks for it in
   play too, for a diagnosis).
+- **Video memory staying over the card's budget once the frame rate falls under 60 fps** (reported on an RTX 4070
+  SUPER at 2560x1440 with DLSS and frame generation, where the frame rate went from 63 to 21 fps): a texture the game
+  has just let go of is kept out of the video memory pressure's reach for 2 seconds, counted in frames. Under 60 fps
+  the count did not shrink, so the 2 seconds were 4 at 30 fps and nearly 6 at 21, and the textures waiting them out
+  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).
 - **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);