Replace manual trash implementation with NSFileManager's trashItemAtURL

[delacrixmorgan]

Summary

Replaces the custom move-to-trash logic in GCFoundation.m with the system-provided NSFileManager.trashItemAtURL:resultingItemURL:error: API (available since macOS 10.8).

Motivation

The previous implementation manually resolved the Trash directory, built a unique destination filename via a while-loop, and performed a file move. This had several issues:

• Race condition (TOCTOU) — A file could appear at the destination path between the existence check and the move, causing failure.
• Incorrect Trash location for external volumes — Always used the user-domain Trash instead of the volume-specific .Trashes, forcing expensive cross-volume copy+delete operations.
• Edge case with extensionless files — stringByAppendingPathExtension:@"" could produce a trailing dot in the filename.

Changes

• GitUpKit/Core/GCFoundation.m: Replaced the 12-line manual implementation with a single call to trashItemAtURL:resultingItemURL:error:.

Risk Assessment

Risk	Severity	Notes
Behaviour change in error reporting	Low	The system API returns its own NSError domain/codes instead of the previous generic error for "Unable to find Trash". Callers that inspect error details (not just success/failure) may see different error objects.
Sandboxed environments	Low	trashItemAtURL: works correctly in sandboxed apps — the app already has the entitlement to access the file being trashed. No change needed.
Deployment target compatibility	None	The API requires macOS 10.8; the project targets macOS 10.13.

Overall this is a low-risk change — it delegates to the same system mechanism that Finder uses, and the deployment target is well above the API's availability.

[delacrixmorgan]

Regarding this, it was a false alarm. It's all good now.
#2779 (comment)