Keep released textures for one minute and up to a thirty-second of the video memory budget.

The textures the game lets go of were kept for three minutes and could hold a quarter of the card's budget, up to
8 GiB with room. A run through Hyrule Field shows what that bought and what it cost (RTX 5090, 5120x2160 with DLSS
Performance, about three minutes of running; the game keeps 4.8 GiB of textures live and loads about 190 a second):
the released textures held 5.3 GiB on average and the video memory in use went from 11.1 to 17.9 GiB, while the
game took back 1,494 MiB of them within 10 s of the release, 171 MiB within a minute and 10 MiB later, beside 33,000
textures it loaded anew. A shorter hold alone gives nothing back: with 20 s the released textures fell to 0.5 GiB
and the free space inside the allocator's blocks rose to 4.9 GiB, since a block returns to the driver only when it
is empty. What the released textures hold at their fullest is what the session costs, so the bound is the lever.

The bound is now a thirty-second of the budget, 384 MiB to 1 GiB (vk_tex_release.h trl_cap_mb), still doubled while
the card and the commit have room, and the hold 60 s, 120 for content only the GPU made. The same run with the new
defaults: 13.2 GiB in use on average against 16.7, 13.8 at most against 17.9, 532 MiB of textures made again over
the run, 77 fps against 75. An 8 GiB card keeps 384 MiB where it kept up to 1.9 GiB.

tests/tex_release_check checks the bound by the budget and the sessions it simulates against the rule before.
Compaction (tex_compact) and 16 MiB blocks were tried on the same run and gave back 0.7 and 1.2 GiB; neither is
changed here.

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

nx2navi.ini.example

@@ -416,14 +416,16 @@
 # left. In play the game took released textures back within a minute or not at all; one taken back after its drop is
 # made again and shows its stand-in for a frame. A texture whose content only the GPU made waits twice as long, and one
 # the GPU drew into since its last copy back to game memory stays. 0: released textures stay up to tex_released_mb for
-# the whole session (as before 0.10). Default: 180. Read at start.
-# tex_released_hold = 180
+# the whole session (as before 0.10). Default: 60 (180 until 0.10.2). Read at start.
+# tex_released_hold = 60
 # Megabytes the released textures may hold (0: no bound). Past it the oldest go even when young; while tex_released_hold
 # is on, young ones may stay past it, up to twice it, as long as video memory and the system's commit have room.
-# Default: a quarter of the video memory budget where the PC has an eighth of its memory to match, at least a
-# thirty-second of the PC's memory (512 to 2048), at most 8192. 1024 (the low of the 0.10 previews) holds less, but
-# textures the game takes back after their drop are made again and show their stand-in for a frame. Read at start.
-# tex_released_mb = 4096
+# What they hold at their fullest is video memory the game keeps for the rest of the session, so this is what the cache
+# costs. Default: a thirty-second of the video memory budget, at least 384 and at most 1024 (until 0.10.2 a quarter of
+# the budget, up to 8192: on a run through Hyrule Field that held 3.3 GB more video memory and saved one texture in
+# thirty from being loaded again). A larger value keeps more textures the game may take back, which are otherwise made
+# again and show their stand-in for a frame. Read at start.
+# tex_released_mb = 1024
 # Texture compaction (experimental). Video memory is taken in blocks (vma_block_mb), and a block goes back to the
 # driver only once everything in it is freed: after a long session the blocks hold textures scattered between holes,
 # and the game holds a gigabyte or two of video memory it does not use. 1: textures no shader sampled for ten seconds