fork: hardlink snapshot mem-file into snapshot forks

[sjmiller609]

Summary

• Snapshot forks now hardlink the source mem-file into the fork's data dir instead of sparse-copying it.
• The mem-file is skipped from the directory walk via CopyOptions.SkipRelPaths, then os.Link'd into place after the copy returns. Dodges the multi-GB sparse copy and the directory-walk overhead in one step.
• Falls back to the normal copy when no raw mem-file is present (e.g. compressed-only snapshot whose decompression failed, or a snapshot kind that doesn't carry guest memory).

Why this is safe

• Snapshot mem-files are immutable.
• The hypervisor mmaps them MAP_PRIVATE on restore, so fork writes never reach the underlying file — all forks of a snapshot can share the same inode.
• Hardlinks survive snapshot deletion via inode refcount, so deleting a snapshot never strands a running fork.
• Same-FS guarantee holds: snapshot dir and fork dir are both under hypeman's data dir.

Stack

• Stacked on hypeship/fork-shared-memfile (PR fork: share template mem-file via symlink for fan-out forks #214) because that PR introduced CopyOptions.SkipRelPaths.
• Independent of the cloud-hypervisor uffd work and PR api: share_memory fork mode + fork_count/mem_locked on Instance #220's share_memory API.

Test plan

• go test ./lib/instances/ -run TestForkSnapshotHardlinksRawMemoryFile
• go test ./lib/instances/ -run TestForkSnapshotFromCompressedSourceCopiesRawMemory still passes (compressed source still gets a real raw file in the fork)
• go test ./lib/forkvm/
• Manual: fork a Standby snapshot, confirm stat -c %i matches between the source mem-file and the fork's mem-file