@@ -338,6 +338,45 @@ jobs:
         run: |
           cargo test -p rustysnes-test-harness --features test-roms \
             --test accuracysnes -- --nocapture
+      # `v1.26.0`: the golden vectors were executed by NO pull-request job.
+      #
+      # Only `lint`, `test-light`, and this job run on a PR. `test-light` does not pass
+      # `--features test-roms`, and the step above scopes itself to `--test accuracysnes` — so the
+      # 53 rendered-scene goldens and every framebuffer golden were reached only by `full-test`,
+      # which is `mode == 'full'` (main, tags, the weekly cron). A PR could shift PPU behaviour,
+      # move a golden, and hear nothing about it until merge-to-main.
+      #
+      # That is the same structure that produced the coprocessor-golden staleness this project
+      # already hit once (goldens left stale by post-bless PPU accuracy fixes): a golden vector
+      # nothing executes only accumulates drift. Here it was not that nothing executed them ever,
+      # but that nothing executed them when it could still be cheap to fix.
+      #
+      # Cost is bounded and known: the three suites with a committed corpus (~5 min total in a
+      # debug build — scenes ~84s, undisbeliever ~158s, rainwarrior ~54s). The `*_oncart`
+      # coprocessor suites need gitignored commercial dumps and firmware, so they self-skip here
+      # for free; they are listed anyway so the intent is explicit rather than inferred from an
+      # omission, and so they start gating the moment a runner ever has that corpus.
+      #
+      # `--no-fail-fast` is load-bearing, not decoration. Cargo's default stops after the FIRST
+      # failing test binary, and it stops across binaries, not just within one — verified by
+      # injecting a failure into `save_state_backward_compat` and watching
+      # `save_state_determinism` never run at all. With ten suites here that would mean one broken
+      # golden hides the status of the other nine, so an author fixes one, pushes, and only then
+      # discovers the next: a serialized debug loop over a ~6-minute job. With the flag, every
+      # suite reports and the step still fails.
+      - name: Run the golden vectors
+        run: |
+          cargo test -p rustysnes-test-harness --features test-roms --no-fail-fast \
+            --test accuracysnes_scenes \
+            --test undisbeliever_golden \
+            --test rainwarrior_golden \
+            --test dsp1_oncart \
+            --test sa1_oncart \
+            --test superfx_oncart \
+            --test dsp3_st011_oncart \
+            --test srtc_st018_oncart \
+            --test save_state_determinism \
+            --test save_state_backward_compat
 
   # v1.5.0 "Bedrock": the one stable required-check name branch protection points at
   # (`docs/adr/0011`). Individual jobs above are conditionally skipped depending on `setup`'s mode,
 
@@ -123,6 +123,19 @@ jobs:
           # ref is compared in `jq` — that is not theoretical, `v1.2` prefix-matches several real
           # tags while exact-matching none.
           #
+          # VERIFIED against the live API, because review challenged exactly this and asserted the
+          # opposite (that `matching-refs` 404s on an absent tag, which would fail every release
+          # closed):
+          #
+          #   matching-refs/tags/v99.99.99          -> HTTP 200, body `[]`, gh exit 0
+          #   matching-refs/tags/zzz-not-a-tag      -> HTTP 200, body `[]`, gh exit 0
+          #   git/ref/tags/v99.99.99                -> 404, gh exit 1   <- the rejected endpoint
+          #
+          # So a non-zero exit here means a REAL failure (network, auth, rate limit) and nothing
+          # else, which is what makes aborting on it correct rather than over-strict. Do not "fix"
+          # this by treating 404 as absent: that would reintroduce the exact three-way collapse
+          # this replaced, letting an auth failure read as "no tag, go ahead and release".
+          #
           # Every failure path aborts the job (the script runs under `set -euo pipefail`) rather
           # than resolving to a release decision.
           if ! matching="$(gh api "repos/${GITHUB_REPOSITORY}/git/matching-refs/tags/${tag}")"; then
 
@@ -9,6 +9,59 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Fixed
+
+- **The golden vectors ran in no pull-request job.** Only `lint`, `test-light`, and `accuracysnes`
+  run on a PR; `test-light` never passes `--features test-roms`, and the `accuracysnes` job scoped
+  itself to `--test accuracysnes`. So the **53 rendered-scene goldens and every framebuffer golden**
+  were reached only by `full-test`, which runs on `main`, tags, and the weekly cron. A PR could
+  shift PPU behaviour, move a golden, and hear nothing about it until merge-to-main.
+
+  That is the same structure behind this project's own coprocessor-golden staleness (goldens left
+  stale by post-bless PPU accuracy fixes): a golden vector nothing executes only accumulates drift.
+  Here it was not that nothing ran them ever, but that nothing ran them while it was still cheap to
+  fix. The `accuracysnes` job now also runs the scene, undisbeliever, rainwarrior, coprocessor, and
+  save-state suites — ~5 minutes for the three with a committed corpus; the `*_oncart` suites need
+  gitignored dumps and self-skip for free, listed anyway so the intent is explicit.
+
+  Found while looking for RustySNES's analogue of the sibling's `expansion_level_tripwire`. That
+  mechanism does **not** port: the only `commercial-roms`-gated suite here
+  (`commercial_screenshots`) is a screenshot generator that asserts nothing, so it holds no golden
+  that can go stale, and PPU accuracy is not parameterised by a small constant set the way
+  expansion-audio levels are. Looking for it surfaced a real and larger gap instead.
+
+### Changed
+
+- **Run-ahead stays opt-in, and the reason is now measured rather than assumed.**
+  `docs/frontend.md` recorded the per-frame save-state allocation as *the* blocker on making
+  run-ahead default-on. `v1.25.0` removed that allocation, so the question was re-measured.
+
+  Absolute timings below are from one development machine and will differ on other hardware — they
+  are recorded because the **ratios** are what decide this, and a reader can only check a ratio by
+  re-running the same two benches (`save_state_cost`, `headless_frame`) and comparing. The
+  percentages are the portable part; the microseconds are the working:
+
+  | | cost |
+  |---|---:|
+  | `save_state` | ~119 µs |
+  | `load_state` | ~285 µs |
+  | **save/load round trip** | **~0.40 ms** |
+  | one emulated frame (`headless_frame_steady_state`) | **6.39 ms** |
+  | NTSC frame budget | 16.64 ms |
+
+  The round trip is **2.4%** of the budget — it was never the dominant cost, and removing the
+  allocation did not move the decision. What run-ahead costs is the extra frame of emulation, which
+  is inherent: `frames = 1` needs **79%** of the NTSC budget on a fast development machine, leaving
+  ~3.5 ms for present, UI, and audio; `frames = 2` needs **118%** and cannot hold 60 fps at all.
+  Defaulting that on would miss deadlines on ordinary hardware to buy latency nobody asked for.
+
+- **`RunAheadConfig`'s `Default` is hand-written so the throttle is armed.** A derived `Default`
+  gave `throttle_ms: 0.0`, which *disables* the throttle — leaving the safety net off for exactly
+  the user who had just enabled run-ahead from Settings and had no `throttle_ms` line in their
+  `config.toml`. It now defaults to 14 ms (below the 16.64 ms NTSC deadline with headroom, and
+  conservative against PAL's 20 ms). An existing config that spells the field out keeps its value;
+  `#[serde(default)]` fills only absent fields, pinned by a negative-control test.
+
 ### Security
 
 - **CI supply-chain hardening — every workflow credential, action pin, and the release gate.**
 
@@ -580,7 +580,26 @@ impl Default for RewindConfig {
 }
 
 /// Run-ahead settings (`crate::rewind::step_with_run_ahead`).
-#[derive(Debug, Clone, Default, Serialize, Deserialize)]
+///
+/// **Run-ahead stays opt-in, and `v1.26.0` measured why.** `docs/frontend.md` recorded the
+/// per-frame save-state allocation as "the blocker on making run-ahead default-on"; `v1.25.0`
+/// removed that allocation, so the question was re-measured rather than assumed resolved:
+///
+/// | | cost |
+/// |---|---:|
+/// | `save_state` | ~119 µs |
+/// | `load_state` | ~285 µs |
+/// | save/load round trip | **~0.40 ms** |
+/// | one emulated frame (`headless_frame_steady_state`) | **6.39 ms** |
+/// | NTSC frame budget | 16.64 ms |
+///
+/// The round trip is **2.4%** of the budget — it was never the dominant cost. What run-ahead
+/// actually costs is the extra frame of emulation, which is inherent to the technique and cannot
+/// be optimised away: `frames = 1` consumes **79%** of the NTSC budget on a fast development
+/// machine, leaving ~3.5 ms for present, UI, and audio; `frames = 2` needs **118%** and cannot
+/// hold 60 fps at all. Defaulting that on would make the emulator miss frames on ordinary
+/// hardware to buy latency the user never asked for.
+#[derive(Debug, Clone, Serialize, Deserialize)]
 #[serde(default)]
 pub struct RunAheadConfig {
     /// Frames to peek ahead each displayed frame. `0` disables run-ahead entirely
@@ -591,11 +610,37 @@ pub struct RunAheadConfig {
     ///
     /// Run-ahead multiplies emulation cost by `frames + 1`, so on a machine that is already
     /// missing its frame deadline it converts a latency improvement into visible stutter. RustyNES
-    /// throttles on a frame budget for exactly this reason; without it the feature cannot safely
-    /// be on by default.
+    /// throttles on a frame budget for exactly this reason.
     pub throttle_ms: f32,
 }
 
+/// The run-ahead budget throttle's default, in milliseconds.
+///
+/// Sits below the 16.64 ms NTSC deadline with headroom for present, UI, and audio, and is
+/// conservative against PAL's 20 ms too. Named rather than inlined so the value, the doc comment
+/// that justifies it, and the test that bounds it cannot drift apart.
+pub const DEFAULT_RUN_AHEAD_THROTTLE_MS: f32 = 14.0;
+
+impl Default for RunAheadConfig {
+    /// Run-ahead off, **but the throttle armed** for whenever it is turned on.
+    ///
+    /// This is hand-written rather than derived for one reason: a derived `Default` gives
+    /// `throttle_ms: 0.0`, which *disables* the throttle. The safety net that
+    /// [`RunAheadConfig::throttle_ms`] exists to provide would then be off for exactly the user
+    /// who just enabled run-ahead from the Settings panel and has no `throttle_ms` line in their
+    /// `config.toml` — the one person who most needs it. Enabling a feature should not require
+    /// separately discovering the knob that keeps it from stuttering.
+    ///
+    /// An existing `config.toml` that already spells out `throttle_ms` keeps whatever it says;
+    /// only an absent field picks [`DEFAULT_RUN_AHEAD_THROTTLE_MS`] up.
+    fn default() -> Self {
+        Self {
+            frames: 0,
+            throttle_ms: DEFAULT_RUN_AHEAD_THROTTLE_MS,
+        }
+    }
+}
+
 /// Autofire ("turbo") settings — hold a face button and the frontend pulses it (`v1.25.0`).
 ///
 /// Purely a host-input convenience: the pulsing happens where host input is sampled, so the core
@@ -880,6 +925,64 @@ mod tests {
         assert_eq!(back.p1.binds.len(), 12);
     }
 
+    #[test]
+    fn run_ahead_is_off_by_default_but_its_throttle_is_armed() {
+        // The trap this pins: a DERIVED `Default` gives `throttle_ms: 0.0`, which *disables* the
+        // throttle. Run-ahead's own doc calls that throttle the thing that keeps the feature from
+        // turning a latency win into visible stutter — so the derived default left the safety net
+        // off for exactly the user who just enabled run-ahead and has no `throttle_ms` line in
+        // their config.
+        let cfg = RunAheadConfig::default();
+        assert_eq!(cfg.frames, 0, "run-ahead must stay additive-default-off");
+        // `assert!(x == y)` rather than `assert_eq!`: clippy's `float_cmp` exempts this form but
+        // fires on the `assert_eq!` spelling, so the more idiomatic-looking one fails the
+        // `-D warnings` gate. Same reason as the note in the test below.
+        assert!(cfg.throttle_ms == DEFAULT_RUN_AHEAD_THROTTLE_MS);
+        assert!(
+            cfg.throttle_ms > 0.0,
+            "the throttle must be armed by default, or enabling run-ahead silently ships \
+             without its safety net"
+        );
+        // Below the NTSC deadline with headroom for present/UI/audio. A throttle at or above the
+        // deadline can never fire before the frame is already late. Derived from
+        // `Region::frame_rate()` rather than a literal 60.0988 so the two cannot drift apart;
+        // compared in `f64` because that is what `frame_rate()` returns, which also avoids a
+        // lossy `as f32` the pedantic cast lints would (rightly) object to.
+        //
+        // ONLY NTSC is asserted, deliberately. Review suggested adding a matching `Region::Pal`
+        // check, since the constant's doc justifies itself against both. Arithmetic says that
+        // assertion could never fail: NTSC's budget is 16.64 ms and PAL's is 20.00 ms, so PAL is
+        // the LOOSER bound by 3.36 ms and `throttle_ms < NTSC` strictly implies
+        // `throttle_ms < PAL`. Adding it would be a vacuous assertion sitting next to a real one
+        // and reading like extra coverage — the exact shape `CLAUDE.md` warns about under "a guard
+        // must not subsume the assertion it protects".
+        assert!(
+            f64::from(cfg.throttle_ms) < 1000.0 / Region::Ntsc.frame_rate(),
+            "a throttle at or above the frame budget fires too late to prevent anything"
+        );
+    }
+
+    #[test]
+    fn an_explicit_throttle_of_zero_survives_the_new_default() {
+        // Negative control for the test above. The new hand-written `Default` must not override a
+        // config that deliberately spells out `throttle_ms = 0.0` to disable the throttle —
+        // `#[serde(default)]` fills only ABSENT fields, and conflating the two would silently
+        // change behaviour for a user who opted out on purpose.
+        let cfg: Config =
+            toml::from_str("[run_ahead]\nframes = 1\nthrottle_ms = 0.0\n").expect("deserialize");
+        assert_eq!(cfg.run_ahead.frames, 1);
+        // `assert!(x == 0.0)` rather than an epsilon dance: this is an exact literal round-tripped
+        // through TOML, not a computed value. Note the form matters — clippy's `float_cmp` exempts
+        // this constant comparison but DOES fire on the `assert_eq!(x, 0.0)` spelling, so the
+        // apparently more idiomatic version fails the `-D warnings` gate.
+        assert!(cfg.run_ahead.throttle_ms == 0.0);
+
+        // ...while an absent field does pick the armed default up.
+        let cfg: Config = toml::from_str("[run_ahead]\nframes = 1\n").expect("deserialize");
+        assert_eq!(cfg.run_ahead.frames, 1);
+        assert!(cfg.run_ahead.throttle_ms > 0.0);
+    }
+
     #[test]
     fn region_frame_rates_and_heights() {
         assert!((Region::Ntsc.frame_rate() - 60.0988).abs() < 1e-3);
 
@@ -584,14 +584,45 @@ no new dependency** — a rewind buffer pulling in a compression crate to store
 
 ### Run-ahead's per-frame allocation (`save_state_into`)
 
-Run-ahead snapshots the machine **every frame**. `EmuCore::save_state` allocates a fresh
-hundreds-of-kilobyte `Vec` each time, which `docs/frontend.md` has recorded as the blocker on making
+Run-ahead snapshots the machine **every frame**. `EmuCore::save_state` allocated a fresh
+hundreds-of-kilobyte `Vec` each time, which this document long recorded as *the* blocker on making
 run-ahead default-on.
 
 `System::save_state_into` (and its `SaveWriter::with_buffer`) reuse a caller-owned buffer, clearing
 it but **keeping its capacity**. Output is byte-for-byte identical; the only difference is that the
 allocation happens once instead of sixty times a second.
 
+#### …was not actually the blocker (`v1.26.0`, measured)
+
+With the allocation gone, the default-on question was **re-measured rather than assumed resolved**:
+
+| | cost |
+|---|---:|
+| `save_state` (`save_state_cost` bench) | ~119 µs |
+| `load_state` | ~285 µs |
+| **save/load round trip** | **~0.40 ms** |
+| one emulated frame (`headless_frame_steady_state`) | **6.39 ms** |
+| NTSC frame budget | 16.64 ms |
+
+The round trip is **2.4% of the frame budget**. It was never the dominant cost, and removing the
+allocation — while a real improvement — did not move the decision.
+
+What run-ahead actually costs is the **extra frame of emulation**, which is inherent to the
+technique and cannot be optimised away. `frames = 1` needs 13.18 ms of a 16.64 ms budget (**79%**),
+leaving ~3.5 ms for present, UI, and audio on a fast development machine; `frames = 2` needs
+19.57 ms (**118%**) and cannot hold 60 fps at all.
+
+**So run-ahead stays opt-in.** Defaulting it on would spend most of every frame's budget — and miss
+deadlines outright on ordinary hardware — to buy latency the user never asked for. The
+`run_ahead.throttle_ms` budget throttle exists to make the feature safe *when a user opts in*, not
+to make it safe as a default.
+
+One thing did change as a result: `RunAheadConfig`'s `Default` is now hand-written so
+`throttle_ms` defaults to **14 ms (armed)** rather than the derived `0.0` (**disabled**). The
+derived default left the safety net off for precisely the user who had just enabled run-ahead and
+had no `throttle_ms` line in their `config.toml`. An existing config that spells the field out
+keeps whatever it says.
+
 The buffer is owned by the caller for a reason: a local `Vec` inside the run-ahead function would
 allocate just the same. The synchronous path keeps one on `Active`; the `emu-thread` build keeps its
 own in `emu_thread::run_loop`, because frame production there lives on a different thread — and a