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>

docs/architecture.md

@@ -391,10 +391,12 @@ keeps per-core data without locks and relies on that, so the host models it (`ru
   by their growth since play began and marks those that only climbed (`mem_growth.h`).
 - Released textures by age: the game releases a texture when what uses it leaves the view and takes it back when that
   returns; the cache keeps the released image so that the take-back finds it. In play the take-backs came within a
-  minute of the release or never, so a released texture goes once it has gone unused for a hold of three minutes, six
+  minute of the release or never, so a released texture goes once it has gone unused for a hold of one minute, two
   for content only the GPU made (`vk_texture.c` `drop_aged`, `vk_tex_release.h`, `tex_released_hold`). The size bound
-  (a quarter of the video memory budget) stays as the safety net for a burst of area changes, and young textures may
-  pass it, up to twice it, while the card and the system's commit have room. Times are wall seconds from a clock of
+  (a thirty-second of the video memory budget, 384 MiB to 1 GiB) is what the cache costs in video memory: the
+  allocator's blocks go back to the driver only when empty, so what the released textures hold at their fullest
+  stays in use for the session. Young textures may pass it, up to twice it, while the card and the system's commit
+  have room. Times are wall seconds from a clock of
   the presents, not present counts. What a switched-off upscaler or SMAA held is freed after it has gone unused for a
   while (`vk_dlaa.c` `idle_release`, `vk_fsr.c` `idle_note`, `vk_aa.c` `work_idle`). What DLSS or FSR lets go of at
   a change of size or mode (a network, an FSR context, a work image) goes once the GPU is past the last submission that