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.