bug: unwritable output paths crash with a raw traceback and abort all remaining usernames

Summary

Output filenames are built by interpolating the raw username (f"{username}.txt" at sherlock.py:833, .csv at :846, .xlsx at :927) with no sanitization and no error handling around the write. Any write failure (path separators in usernames, nonexistent directories, permissions) produces an uncaught traceback and aborts the entire run — usernames listed after the failing one are never queried.

Observed behavior

$ sherlock --timeout 5 --site GitHub --txt "a/b"
...
FileNotFoundError: [Errno 2] No such file or directory: 'a/b.txt'      # sherlock.py:836

$ sherlock --timeout 5 --site GitHub --csv "a/b"
FileNotFoundError: [Errno 2] No such file or directory: 'a/b.csv'      # :853

$ sherlock --timeout 5 --site GitHub --xlsx "a/b"
OSError: Cannot save file into a non-existent directory: 'a'           # :927 via to_excel

$ sherlock --timeout 5 --site GitHub --output /nonexistent/dir/f.txt --txt daniel
FileNotFoundError: ... '/nonexistent/dir/f.txt'                        # :836

$ sherlock --timeout 5 --site GitHub --txt "a/b" ok1                   # multi-username
# crashes on first username; ok1 is NEVER queried (workdir empty), exit 1

Related: #2025 reports the same FileNotFoundError symptom for an explicitly-passed --output path in Docker, but not the username-derived-path case, the xlsx case, or the multi-username abort. No open PR covers fail-soft write handling or sanitization (checked against the #2992 family #3083/#3039/#2993 and #2891/#3077 — none touch this).

Proposal

Wrap each report write (:836, :853, :927) in try/except OSError → print a clear per-format error and continue to the next username (fail-soft). This preserves the rest of the run instead of killing it on one bad path.

Open questions (not blocking):

• Explicitly-passed --output failing might arguably warrant exit 1 rather than soft-continue — happy to follow maintainer preference.
• Whether to also sanitize (a/b → a_b) is a separate product call; silently renaming usernames may be seen as mangling input, so this proposal keeps behavior error-and-continue only.