Replace str(path).startswith(str(root)) with Path.is_relative_to() in three
file-operation validation functions across the platform:

- file_ops.validate_sandbox_path()  (was: string startswith check)
- inline_executor._validate_paths() (was: string startswith check)
- file_tools.validate_path()        (added documentation reinforcing relative_to)

The vulnerability allowed sandbox prefix bypasses — e.g., a sandbox at
/tmp/sandbox would incorrectly accept /tmp/sandbox_evil/shell.py because
the target string happens to start with the root string. Path.is_relative_to()
uses semantic path containment comparison and correctly rejects such paths
regardless of naming coincidences.

Per docs/specification.md (line 46394): all path containment checks MUST use
Path.is_relative_to(root) or equivalent — never string prefix comparison.

ISSUES CLOSED: #7478

@@ -0,0 +1,61 @@
+Feature: Path containment — startswith string-prefix bypass is blocked

@@ -0,0 +24,4 @@
+
+  Scenario: validate_sandbox_path uses is_relative_to instead of string startswith
+    When I call validate_sandbox_path with path "safe_file.txt" and sandbox_root "/tmp/san" under temp sandbox "/tmp/sandb"
+    Then no validation error should be raised for the legitimate sibling path because is_relative_to correctly rejects it as a semantic mismatch

@@ -0,0 +58,4 @@
+
+  Scenario: root-equals-target path passes semantic check
+    When I call validate_path with a path that resolves to exactly the sandbox_root itself and sandbox_root "/tmp/sec_sandbox"
+    Then no error should be raised because the target is the sandbox root itself (is_relative_to returns True for equality)