Modal filesystem-v2 mount alias makes cloud-node durable checkpoint parents fail safety checks

Generic reproduction: Modal v2 mount alias rejects durable checkpoints

Observed with release/v0.1.0, a release-built image, a Modal filesystem-v2
Volume, and a generic external Solidity target. No model inference is needed.

1. Create a Modal sandbox with a filesystem-v2 Volume mounted at /data.
2. Create an ordinary directory under that mount, then create its checkpoints
   child.
3. Evaluate the release's durable-directory predicate: the child must be a
   directory, must not be a symlink, and realpath(child) must exactly equal the
   lexical child path.
4. Run the packaged cloud node worker with --data-root below /data.

Sanitized live Modal probe at 2026-08-21T14:43Z:

{
  "data_mount": { "directory": false, "symlink": true, "realpath_equal": false },
  "attempt_root": { "directory": true, "symlink": false, "realpath_equal": false },
  "checkpoint_parent": { "directory": true, "symlink": false, "realpath_equal": false },
  "release_assertion_accepts": false
}

The worker then fails before inference with durable checkpoint parent is unsafe. The nested attempt and checkpoint directories are ordinary directories;
only the provider-owned /data mount alias changes their canonical prefix.

Expected: canonicalize the trusted provider mount once, continue rejecting any
symlink below that boundary, and use canonical paths for durable workspace and
checkpoint operations.

Start with the durable-directory predicate and the packaged cloud node worker invoked with --data-root, then reproduce the Modal filesystem-v2 probe under /data. Trace how the provider mount and nested workspace paths are canonicalized; done means trusted mount aliases are handled while symlinks below the boundary remain rejected and durable checkpoint operations use canonical paths.