Describe RivaTuner Statistics Server's hand-off, the pacer's fallbacks and rtss-profile.txt as they behave now.

docs/architecture.md said the pacer holds nothing while RTSS holds the limit, through movies and minimised windows,
that the pacer stands aside once RTSS lists the process, that RTSS fails at 1.2 times the limit over six polls, and
that a killed run leaves its limit for the next run to take as the player's. The one-limiter and RTSS paragraphs now
name the pacer's fallbacks (before the first host present, a movie, 200 ms with no host present, a limiter seen
letting frames through, any failure) and its 240 ceiling beside RTSS, the settle rule, a movie's profile, the proof
RTSS must give before the pacer stands aside, the 1.05 rule over three new periods, the rounding down, and the state
file with rtss_limit_crash. nx2navi.ini.example's rtss lines, README.md's frame generation item, docs/building.md's
rtss_limit_check and frame_step_check paragraphs and rtss_limit.c's header follow, and the comments at main.c
crash_handler's and dispatch.c fatal_end's rtss_limit_crash say when RTSS's library is still called there (no line in
the state file, never on RTSS's own thread). No code changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

nx2navi.ini.example

@@ -24,14 +24,15 @@
 # game draws the monitor's rate divided by the multiplier.
 # fps_limit = 60
 # Where RivaTuner Statistics Server is installed and running, the limit goes into its profile for the game's
-# executable and RTSS does the limiting instead of the game; closing the game puts back what the profile held.
-# Changing that profile needs the game run as administrator (RTSS keeps its profiles under Program Files). Without it
-# the game limits by itself, as it does with frame generation on (RTSS would count the generated frames) and for the
-# rest of the run when RTSS's own frame counter shows the game well past the limit (RTSS then hooks the game without
-# holding it back); with low latency on, the driver holds the limit. rtss = 0 always leaves it to the game. With
-# rtss = 0, frame generation or low latency, a limit set in RTSS itself (its global profile or the game's, a frame time
-# limit or scanline sync) limits the game a second time: the log and the settings menu say so, and setting it to 0 in
-# RTSS leaves one limiter.
+# executable and RTSS does the limiting instead of the game, once RTSS is seen holding the game to it; closing the game
+# puts back what the profile held, and after a crash or a kill the next start does (rtss-profile.txt next to the game
+# keeps what it held). Changing that profile needs the game run as administrator (RTSS keeps its profiles under Program
+# Files). Without it the game limits by itself, as it does with frame generation on (RTSS would count the generated
+# frames), while a movie plays or the window is minimised, and for the rest of the run when RTSS's own frame counter
+# shows the game past the limit (RTSS then hooks the game without holding it back); with low latency on, the driver
+# holds the limit. rtss = 0 always leaves it to the game. With rtss = 0, frame generation or low latency, a limit set in
+# RTSS itself (its global profile or the game's, a frame time limit or scanline sync) limits the game a second time:
+# the log and the settings menu say so, and setting it to 0 in RTSS leaves one limiter.
 # rtss = 1
 # 1: asks RTSS's EnumProfiles whether the game's profile exists, instead of looking for its file. EnumProfiles crashes
 # the game (RTSS keeps a pointer of the game's in 32 bits); only for testing an RTSS that fixed it.