Fix path detection crash on long command strings

[cdakotabrown]

Summary

Fixes a bug where excessively long command strings or path tokens could crash the attachment detection logic with OSError (ENAMETOOLONG) or cause unexpected behavior during file path resolution.

Changes Made

• Added early length validation: Skip path candidates that exceed MAX_PATH_LENGTH (1024 chars) before attempting filesystem operations
• Added OSError exception handling: Gracefully handle OS-level errors (like ENAMETOOLONG) when checking if paths exist, preventing crashes on edge-case inputs
• Improved robustness: The path detection loop now continues to the next candidate instead of failing when encountering invalid path lengths

Technical Details

Problem

When users entered very long command strings or pasted content with lengthy text spans, the _detect_path_tokens() function would:

1. Attempt to normalize and check paths that were too long for the OS to handle
2. Throw unhandled OSError exceptions when calling path.exists() or path.is_file()

Solution

Two-layer defense:

1. Pre-check: Added len(candidate_path_token) > MAX_PATH_LENGTH check before path normalization to skip obviously-too-long candidates early
2. Exception handling: Wrapped filesystem existence checks in try/except to catch any OSError that slips through (belt and suspenders approach)

Design Decision

Used continue instead of break in the exception handler to allow the algorithm to try shorter path candidates that might still be valid.

Files Modified

File	Changes
code_puppy/command_line/attachments.py	+13/-5 lines - Added length validation and OSError handling in _detect_path_tokens()

Testing

• Verified that normal file attachments (e.g., @path/to/file.py) still work correctly
• Confirmed that excessively long strings no longer crash the attachment parser
• Edge cases with paths near the MAX_PATH_LENGTH boundary handled gracefully

Breaking Changes

None. This is a pure bug fix with no API or behavior changes for valid inputs.