docs(timing): retire the "48 kHz / 60 fps" statements #448 falsified

Three places still asserted the pre-#392 contract, all found by review on
that PR and all comment/doc only -- no behaviour change:

- `dac.c` SoundCallback: "keeps the delivered rate exactly on the advertised
  48 kHz (800 x 60 fps)". Both numbers were false after #448. This is the
  sentence that justifies the fixed-length batch, so it is the one a future
  reader would most likely trust.
- `jaguar.c` above HalflineCallback: "Each field is created in 1/60s (NTSC)
  or 1/50s (PAL)" sat three lines above #448's own "not 60/50", so the same
  contiguous block asserted both.
- `docs/frontend-pacing.md`: the canonical av_info contract table still read
  60/50 and 48000/48000, and `test/test_frontend_pacing.c` cites this doc as
  its contract. Now carries the real numbers plus a note on what changed and
  why the invariant is unchanged.

Co-Authored-By: Claude Opus 5 <[email protected]>

docs/frontend-pacing.md

@@ -10,14 +10,21 @@ core. Read this before adding one, and before filing it as a core bug.
 
 | field | NTSC | PAL |
 |---|---|---|
-| `timing.fps` | 60 | 50 |
-| `timing.sample_rate` | 48000 | 48000 |
+| `timing.fps` | 60.05445 | 50.08013 |
+| `timing.sample_rate` | 48043.6 | 48076.9 |
 
 `retro_run()` submits audio exactly once per frame via
 `SoundCallback()` (`src/jerry/dac.c`), with `BUFNTSC / 2 = 800`
-sample-frames for NTSC and `BUFPAL / 2 = 960` for PAL. Both work out to
-exactly 48 000 sample-frames per emulated second, so the advertised timing
-and the samples actually produced agree.
+sample-frames for NTSC and `BUFPAL / 2 = 960` for PAL. Multiplied by the
+*true* field rate (524 halflines x 31.777778 us -> 60.05445 Hz; 624 x 32.0 ->
+50.08013 Hz) that is 48043.6 and 48076.9 sample-frames per emulated second,
+which is what `sample_rate` now advertises, so the advertised timing and the
+samples actually produced agree.
+
+Until #392 both rows read 60/50 and 48000, which agreed with each other but
+not with the machine: the emulated field has always been 524/624 halflines,
+never 1/60 s. The agreement below is the same invariant, now stated in real
+numbers.
 
 **That agreement is load-bearing.** If the core submitted more samples per
 second than `sample_rate * 1` implies, the frontend's audio buffer would

src/core/jaguar.c

@@ -1215,7 +1215,9 @@ double JaguarGetFieldRateHz(void)
 
 // Normally, TVs will render a full frame in 1/30s (NTSC) or 1/25s (PAL) by
 // rendering two fields that are slighty vertically offset from each other.
-// Each field is created in 1/60s (NTSC) or 1/50s (PAL), and every other line
+// Each field is created in 1/60.05445s (NTSC) or 1/50.08013s (PAL) -- see the
+// field-rate derivation below; 60/50 are the round numbers, not the rates --
+// and every other line
 // is rendered in this mode so that each field, when overlaid on each other,
 // will yield the final picture at the full resolution for the full frame.
 //

src/jerry/dac.c

@@ -377,7 +377,11 @@ void SoundCallback(void * userdata, uint16_t * buffer, int length)
     * what it last received.
     *
     * The batch stays a fixed `length`, which is what keeps the
-    * delivered rate exactly on the advertised 48 kHz (800 x 60 fps).
+    * delivered rate exactly on the advertised rate (800 pairs x the
+    * field rate = 48043.6 Hz NTSC, 960 x 50.08013 = 48076.9 Hz PAL).
+    * It read "the advertised 48 kHz (800 x 60 fps)" until #392 made
+    * both advertised numbers real; the reasoning was always the
+    * fixed batch, not the round number.
     * Submitting the short count instead lost the 0.27 remainder every
     * frame -- 108 samples/sec of deficit that drained the frontend's
     * buffer until it underran, a pop every few seconds in every title.