Expose the reboot kind (crash vs. crash-and-wipe) to a restarted process

Start at the attrition injector and FaultContext::restart, then follow the boot path through SimContext or the Process factory so the reboot kind reaches the new incarnation before storage opens. Add a same_seed_replays_identically-style test that compares reboot-kind sequences per IP across two runs, and document the API under Process / Workload Separation.

Downstream evidence (paros)

paros does not use moonpool's storage layer: its durable state lives in a harness-owned in-memory "storage world" behind the high-level NodeStorage seam (see PierreZ/paros AGENTS.md, Storage direction). That means Chaos::Attrition's prob_wipe is inert for paros — it wipes moonpool storage files, which hold nothing.

paros #124 (M4.6, reconfiguration under the full fault matrix) needs the wiped node case: a node that lost its whole disk, including its durable Paxos promise, must never rejoin as the same identity and must be replaced by reconfiguration. Today the paros harness models this with its own coin drawn at a chaotic restart (StorageWorld::wipe), which is a paros-side stand-in: the wipe is not part of moonpool's swarm mask, and a recipe/explorer timeline cannot select it as an attrition outcome.

Smallest requested behavior

When a process boots after an attrition reboot, let it learn how it was rebooted, so a harness-owned disk can honor CrashAndWipe itself. Any of these would do:

• SimContext::last_reboot(&self) -> Option<RebootKind> (or a wiped: bool), populated by the attrition injector / FaultContext::restart, None on the first boot; or
• a Process::run argument / ProcessBoot { kind } passed to the factory-created instance; or
• an event on the timeline the process can read at boot (weakest; a trace read is the thing paros avoids).

Deterministic replay constraints

• The kind must be part of the deterministic schedule: same seed, same reboot kinds, and a recipe replay must reproduce them.
• It must be visible to the new incarnation before it opens its storage, with no extra randomness draw (so existing seeds keep their draw order).
• AttritionVictims::group scoping should apply unchanged.

Acceptance criteria

• A Process restarted by Attrition with prob_wipe > 0 can observe whether this boot follows a wipe.
• same_seed_replays_identically-style test: two runs of one seed report identical reboot-kind sequences per IP.
• Book section under Process / Workload Separation documents the API.

Linked from paros PR for #123/#124/#125 (branch claude/paros-issues-123-124-125-cz6qiw).