Prevent workspace ownership changes racing checkpoint file restore

Checkpoint file-restore isolation is checked against recorded thread/workspace ownership at command admission and again before provider rollback. These are observations, not an atomic workspace reservation.

An existing race remains: restore A passes its last check; thread B then registers/starts in an overlapping directory; A restores the checkout and can overwrite B's files. This also existed for equal paths before the parent/child ownership fix in #12338. CheckpointService's workspace mutex serializes checkpoint operations, while thread creation and provider work do not acquire it, so merely changing its key to a canonical path does not close the admission race.

Coordinate workspace ownership registration and filesystem restore. Cover thread creation, workspace/path changes, and provider cwd registration, including canonical aliases and parent/child directories. A new owner must not start writing while a destructive restore is in progress. Avoid holding the SQLite transaction or a global command lock across provider rollback or slow Git work, which would block unrelated threads and may deadlock provider event persistence.

Add a receipt/Deferred-based regression that pauses a restore after its isolation check, attempts an overlapping thread start, and proves the other thread's files remain intact. Shared main behavior needs the protection; v2 requires its own admission integration when inheriting it.

Start by tracing CheckpointService's workspace mutex and isolation checks, then follow thread creation, workspace/path changes, and provider cwd registration. Use a receipt/Deferred regression that pauses restore after its isolation check and attempts an overlapping thread start. Done means shared main behavior preserves the other thread's files without holding SQLite transactions or global locks across rollback or slow Git work; v2 has its own admission integration.