Disk-buffered recording and crash recovery

[ruccho]

Closes #39.

Adds an opt-in disk buffer to RealtimeInstantReplaySession. Encoded frames are written to
segment files instead of being held in memory, which lowers memory pressure and makes the
footage leading up to a crash recoverable for bug investigation.

Disabled by default. Enable with:

var options = RealtimeEncodingOptions.Default;
options.DiskBuffer = DiskBufferOptions.Default;

Recover after a crash:

foreach (var session in DiskEncodedFrameBufferRecovery.FindRecoverable())
{
    var path = await session.ExportAsync(seconds: 30);
    session.Delete();
}

MaxDiskUsageBytes is a hard bound

It bounds the whole session directory — manifest, codec configuration, and every segment — and
it is a bound rather than a target. Space is reserved before each write and the oldest segments
are deleted to make room; when the bound still cannot be met the record is dropped rather than
written. The directory never exceeds the limit at any instant, not even transiently between a
write and a subsequent eviction. Segments rotate at video key frames, so discarding one never
leaves a partial group of pictures behind.

Flush policy

The default, DiskBufferSyncMode.OperatingSystem, hands data to the operating system after
every batch and to the storage device only when a segment is closed. Frames therefore survive a
process crash — a native fault, an OOM kill, or an abort — which is what crash recovery targets,
without a device flush per frame. Power loss or a kernel panic loses at most one segment. The
manifest and codec configuration always reach the device immediately.
DiskBufferSyncMode.EveryRecord trades markedly higher flash wear for durability against power
loss.

Crash recovery works on every platform

Codec configuration is written to a dedicated file that is never evicted, and the reader treats
its absence as normal. Recovery therefore succeeds both on platforms that emit configuration
records (Android MediaCodec, Windows Media Foundation, FFmpeg) and on those that carry the
parameter sets inside every sample and emit none (Apple VideoToolbox, WebCodecs).

Records carry a CRC-32 and are only appended, so a file truncated by a crash recovers up to the
last complete record. The live export path and the recovery path share one reader, one
selection, and one muxing helper, so every export exercises the recovery code.

Verification

The storage layer has no dependency on UnityEngine and is exercised outside the Editor:

cd InstantReplay.Externals/src/InstantReplay.DiskBuffer.Tests && dotnet run

Checks cover the record round trip, recovery from truncated and corrupt files, the hard bound
under sustained eviction, survival of codec configuration across full eviction, key-frame
alignment of segments, the manifest, and selection. The final check drives the real platform
encoder, recovers from the files alone, and muxes; on macOS the result is a valid MP4 that
ffprobe and ffmpeg accept.

Design and rationale: docs/disk-buffered-recording.md.

Not yet verified

Not run inside the Unity Editor, and crash recovery has not been exercised on a device.