fix: include the escaped path in the control-characters path error

[esnunes]

Summary

Supersedes #371 by @waltflanagan, keeping its commit and building on it. Thanks for the fix, Mike!

When File.Path rejects a path containing control characters, the error now says which path was rejected, and the path is rendered in its escaped form so the offending character is visible:

Path contains control characters: "/tmp/foo\nbar"

Why the extra change on top of #371

#371 interpolated the raw path into the message. Because the path contains a control character by definition, the character itself was invisible or destructive in the output: a bare LF split the message across two lines, and a bare CR overwrote the text before it. Using the path's debugDescription prints the escaped form instead, which is what someone debugging the error needs to see.

Changes

• File.Path.Error.containsControlCharacters carries the original path string (from fix: print path triggering containsControlCharacters error #371).
• The description uses path.debugDescription so control characters are escaped.
• Pattern let is hoisted to satisfy the repository's swiftformat rules.
• New FilePathErrorTests cover the associated value, the escaped description for LF, CR, NUL and TAB, and the message surfacing through the public FileSystem API.

Notes

File.Path.Error still does not conform to LocalizedError, so localizedDescription returns Foundation's generic text. This is intentional: the primitives module is Foundation-free. Neither this library nor the Tuist CLI reads errors through localizedDescription; the CLI falls through to CustomStringConvertible.description for this error type, so users see the message above.

Validation

• swift test passes locally on macOS.
• swiftformat --lint is clean on the new test file; the only remaining warning on the vendored source file is the pre-existing file-header one.

🤖 Generated with Claude Code