[follow up on #1259] gpu witnessgen flow

[hero78119]

summary of data life cycle during entire proving

• During opcode assignment
  • shard raw GPU state is uploaded / kept resident:
    • StepRecord
    • shard metadata
    • shared shard buffers as needed
  • GPU still runs assignment-time kernels for side effects:
    • LK multiplicity
    • shardram / shared-circuit accumulation
  • witness trace is not kept as an eager RMM anymore
  • per-chip replay plan is recorded
• During commit_traces
  • no full witness set is resident up front
  • for each trace, deferred commit does:
    • regenerate that chip’s witness/device backing from resident raw shard GPU state
    • commit that one trace
    • drop that transient witness before moving to the next trace
  • after commit finishes, only raw shard GPU state remains resident
• During per-chip proof
  • before a chip task proves, replay regenerates that chip’s witness/device backing from raw shard GPU state
  • chip proof uses it
  • task-local witness is dropped after that chip finishes
  • raw shard GPU state stays resident across all chip proofs
• During PCS opening
  • replay regenerates the needed witness/device backing again from raw shard GPU state
  • opening uses it
  • transient witness is dropped afterward
• At shard end
  • shard raw GPU state is released
  • replay/session metadata is invalidated

So the intended steady-state invariant is:

• persistent across shard proof:
  • raw shard GPU state only
• transient on demand:
  • witness/device backing per trace / per chip / per opening step

Two nuances:

• Initial assign still runs GPU kernels because side effects are needed then, but it no longer keeps eager witness RMMs in cache-none mode.
• The remaining OOM is now later in chip proving, not in commit, which is consistent with this lifecycle shift.