v0.6.0

Added

• World rollback (issue #2, stage 1): [AtlasScenario(RollbackWorld = true)] restores the class
  host's world to its snapshot before the scenario runs, in the same lifecycle slot where
  FreshWorld = true recycles the whole host today, but without rebooting the server (measured
  at roughly 25x faster than a recycle on the baseline superflat world). The snapshot is
  captured lazily, once per host, at the class's first rollback-enabled scenario, so classes
  that never opt in pay nothing. A rollback restores blocks, block entities, chunk-stored
  entities, chunk moddata, savegame data and the calendar (dimension 0); it does NOT restore mod
  in-memory state that ignores chunk/entity lifecycle events, nor in-memory map chunk state
  (height maps, map moddata). Fail closed: if capture or restore fails for any reason (including
  engine internals drifting in a future game version), Atlas logs a one-line warning to stderr
  and falls back to the full host recycle, so the scenario still gets its clean world. Guard
  rails: requesting a rollback on a class that has joined test players fails the scenario with
  AtlasSetupException (player state would not be rolled back; players + rollback is a later
  stage), and combining RollbackWorld with FreshWorld is a setup error.

• atlas run --worker: worker execution mode for the CLI, stage 1 of the multi-process
  parallelization design (issue #1). --worker runs the assembly exactly like plain run
  (one process, sequential, same exit codes) but reports exclusively as line-delimited JSON
  events on stdout: run-start, class-start, test-pass/test-fail/test-skip,
  class-end, error, run-end, every line versioned with v: 1. All human and engine
  chatter (the embedded server logs to the console) is rerouted to stderr, and a fail-safe
  guarantees the stream always ends with a well-formed run-end even when the run crashes.
  --classes <A,B> (worker mode only; a usage error without --worker) restricts the run to
  the given scenario classes by exact fully qualified name, and --list --worker emits one
  discovered event per scenario without booting anything: together they are the seam the
  stage 2 orchestrator (--parallel N) will drive. The protocol contract is documented in
  docs/specs/2026-07-06-worker-protocol.md.

• atlas run --parallel [N]: multi-process orchestration over the assembly's scenario classes,
  stage 2 of the parallelization design (issue #1). The orchestrator discovers the classes
  without booting anything, then drains a greedy per-class queue with N worker subprocesses
  (each one atlas run <dll> --worker --classes <class>: one live server per worker, one class
  per dispatch, workers pull the next class as they free up). N defaults to
  min(max(1, cores / 2), class count). Results stream back over the stage 1 JSONL protocol and
  print live per test; the final summary adds per-class wall clocks and the speedup versus the
  sum of class times (what running them back to back would have cost). A worker that dies
  without a well-formed run-end, exits nonzero without a failing scenario, or outlives
  --worker-timeout <seconds> (default 600 per class; the whole worker process tree is killed)
  is translated into a synthesized failed class carrying a stderr tail for forensics, and the
  queue keeps draining: a crashed worker can fail its class, never shorten the test list.
  --trx <path> writes one aggregated VSTest-style TRX report covering every class, so CI
  artifact upload and TRX tooling keep working without dotnet test. --parallel is
  incompatible with --worker and --list; --worker-timeout and --trx require it.