process-gap(test-writer+adversary): producer-only orphaned-output — derived runtime value exposed but never consumed by target subsystem; producer-only tests false-green (derived-value analogue of #289)

## Class of failure

A story produces a **derived runtime value** (a computed field, multiplier, or signal payload) that is intended to drive another subsystem — but **no production code ever consumes it**. The producing story's tests assert the *producer* side (value is computed/exposed correctly) and pass. The consumer never exists, so the end-to-end behavior is unimplemented, yet every test is green. The output is **orphaned**, mirroring #289's orphan *component* but on the **derived-value / cross-subsystem axis**.

## Pattern observed (ftc-blue pilot, STORY-12.12.001 ↔ STORY-6.06.001)

- `GameManager.apply_assist_settings()` derives `curator_speed_multiplier = curator_speed_pct / 100.0` and exposes it. Tests assert the derivation across the valid range — all green.
- The consumer, `CuratorSystem`, has a `set_speed_multiplier()` API — but **the only caller is another story's unit test**. No production code path reads `GameManager.curator_speed_multiplier` or calls `set_speed_multiplier()` with it. Grep for production readers: zero.
- Result: the assist slider visibly moves, the multiplier is computed and stored, every test passes — and the curator's speed never actually changes in the running game. A model-diverse adversary pass caught it as HIGH; six prior passes + two adversary framings + the e2e suite all missed it because every test asserted only the *producer*.

Contributing root causes (each its own smell):
1. **Producer-only coverage:** no test asserts that a derived runtime field has ≥1 *production* reader.
2. **Per-story perimeter blindness:** the consumer lived in a *merged sibling subsystem* the adversary wasn't shown — the producing story's review perimeter didn't include the consumer's code.
3. **False dependency claim** (see companion issue on dependency-provenance): the producing story asserted that the sibling story "provides the read path," which it did not.

## Why existing issues don't cover it

- **#289** (orphan-component / Integration-Wiring AC): about a *component* (node/autoload/dispatcher) that subscribes to input/signals but is never instanced in a production scene. This is about a *derived value* that is computed and exposed but never *read* by its target subsystem. Different artifact (data vs component), different test axis (reader-existence vs scene-reachability). #289's Integration-Wiring AC, as written, wouldn't require a "value X has a production consumer" assertion.
- **#299** (value duplicated across N surfaces, partial-fix): about propagating a *real, consumed* value to all its surfaces. Here the value has exactly one producer surface and **zero consumer surfaces** — the opposite problem.

## Proposed remediation

1. **Positive consumer-coverage assertion (test-writer convention):** for every *derived runtime field* (a value computed by one subsystem to influence another), require a test asserting at least one **production** code path reads it / is driven by it. "Producer-only" test sets should be flagged.
2. **Cross-subsystem integration-test convention (wave gate):** when a story exposes a value consumed by a *different* subsystem, require a wave-level integration test exercising producer→consumer, and ensure the adversary's review perimeter spans **both** subsystems (not just the producing story's files).
3. **Adversary lens:** "for each newly-derived/exposed runtime value, grep for a production reader; if the only callers are tests, flag orphaned-output."

## Operational impact

User-visible control (assist slider) that silently does nothing in production while all tests pass — false-confidence at the merge gate. Per #325 this is a behavioral no-op shipped green.