TSC offset randomization on restore

[WaylandYang]

Problem

All children resume with parent's TSC value. Identical wall-clock across children opens timing attacks and breaks log correlation.

Approach

Firecracker exposes TSC config on snapshot/restore. Surface via forkd-vmm::ForkOpts.

Acceptance

• ForkOpts { randomize_tsc: true } produces children with distinct TSC offsets
• Default = true

[WaylandYang]

Maintainer triage: keep open as needs-verification before implementing anything. DESIGN.md says Firecracker assigns a fresh tsc_offset on restore, but the repository has no executable regression test or implementation evidence for that claim, and the upstream snapshot documentation does not make it a closure-grade guarantee.

First add a Linux/KVM test that restores at least two children from the same snapshot and compares an observable TSC/clock signal. If uniqueness is demonstrated, close this with the captured evidence and tighten the design-doc wording; otherwise implement the offset change with that test as the acceptance gate.