docs: consolidate static-resource-envelope.md into signed bounded-input-cost-envelope-scheduling.md

docs/plans/bounded-input-cost-envelope-scheduling.md

@@ -86,6 +86,15 @@ Phases are ordered; each closes at a named consumer tier (mirrors §2 fleet acce
 - Drop Predicted cost from runnable → width fold fails closed / refuses over-wide spawn
 - Affected witness skipped on touched dep → selection soundness RED (independent of this design, but scheduling must not bypass it)
 
+## 11. Folded deltas (from the retired `static-resource-envelope.md` draft, 2026-07-03)
+
+That draft (dispatched from `vivid-carp-243` → `merry-koi-140` → revived under `floor-width-budget-source-a`) forked this doc's `InputEnvelope`/width vocabulary and was retired as scope moot under the current convergence (CI de-prioritized). Its census (§4/§8 there) was a point-in-time re-verification of load-bearing sites, not unique design and is dropped; these four points *are* unique thinking not otherwise captured here, folded in as additions per §3/§9's existing convention (not new types):
+
+1. **N-axis width, beyond memory+cpu.** §5's formula reconciles memory and cpu_bound. When storage and energy caps are eventually instrumented, the same `min(...)` reconciliation extends per-axis (`width_storage`, `width_energy` alongside `width_memory`/`width_compute`) over a per-Runnable demand vector — do not fuse storage bytes onto `ByteSize`/`Memory` (a distinct `Quantity` is needed, e.g. `Storage`/`DiskSize`); this is a P2/P3 extension, not a new carrier family.
+2. **Provenance-as-metric.** A `DemandProvenance = StaticDerived | Measured | ConvergedState | Fixture` field on declared bounds/demand would let admission distinguish a real ceiling from `Fixture` scaffolding (mirrors `EnvelopeUnknown => RefusedUndeclared` — a `Fixture`-provenance bound is *declared but not yet grounded*, a different failure mode from *undeclared*) and would make `static_derived_fraction(bounds) -> Percent` a quantitative version of the "input-starved" thesis. Candidate home: `InputBound` and/or the per-Runnable demand vector (P1-consumer follow-up, since `InputEnvelope` has live consumers already).
+3. **`InputEnvelope` streaming projection.** `BoundedInput` today assumes a finite, known-at-admission corpus. A streaming/incremental consumer has a *rate*, not a count — rather than a sibling envelope type, `BoundedInput` could carry a second bound-kind projection (`FiniteKnown` vs `RateBounded { rate, burst, window, backlog }`) answering the same `input_admitted` question against a rate ceiling. `RefusedOverEnvelope`/`RefusedUndeclared` stay projection-agnostic. P1-consumer follow-up, not P0/P1 here.
+4. **Cost-model single authority beyond scheduling.** The per-axis magnitude record this design's `CostEnvelope`/width-fold reads (§3b, §6) should not become scheduler-private: the complexity lens's asymptotic-class analysis asks "what order does this axis grow in," the scheduler asks "does this fit the cap" — both over the same declared/derived magnitude. A second scheduler-local taxonomy would re-fork what this doc already keeps singular. Direction only; confirm before any P2/P3 lens assumes it. Relatedly: space-like axes (memory/storage) should schedule on the upper bound (asymmetric OOM failure), time-like axes (compute-as-thread-seconds) may schedule on average/p95 (degraded, not crashed) — worth stating explicitly whenever P2/P3 extends beyond a hard per-axis cap.
+
 ## Dissolution trigger (DESIGN §6)
 
 Delete this doc when `gunbc_ci_corpus_envelope` carries derived `BoundedInput` ceilings (P5), every floor `Runnable` carries Predicted `CostEnvelope`-derived cost, `spawn_width` is derived from `WidthBoundedRealization` (no side-channel), `gunbc.fleet_intent.PerformanceReceipt` falsifies Predicted with a discriminating RED, runtime admission consumes `input_admitted` on the live floor path, and the selection/scheduling axis split is witnessed — at which point the carriers state the policy and companion trackers (`resource-aware-scheduler.md`, `input-envelope-roadmap.md`) may dissolve.