Shared memory budget: an optional cache can starve the producer thread

In a producer/consumer pipeline where both threads reserve from one memory budget, an optional component on the consumer side, such as a derived index or cache with a reserved pool, can make the PRODUCER's reservation fail. The component's degrade-on-failure path only runs when its own allocation fails, so nothing degrades and the run aborts. The fix is to let a failed producer reservation enqueue a 'drop optional data' job, run it on the consumer thread between units of work, never inside the component's own code, and retry the reservation once. Also hand any container capacity the dropped component held back to the budget right away; a lazy true-up at the next accounting point leaves the bytes counted until then. Note too that under budget pressure, whether the optional data survives becomes timing-dependent, so tests must accept either outcome, e.g. output == the no-cache output.