fix: exit 0 when a downstream reader closes stdout early

[varuntej07]

Problem

Piping graphify into a reader that stops early (head, PowerShell
Select-Object -First N, a pager that quits) closes stdout before we finish
writing. The interpreter's shutdown flush then hits the closed pipe and crashes:

Exception ignored on flushing sys.stdout:
OSError: [Errno 22] Invalid argument

The process exits nonzero (120 on POSIX). A downstream head closing the pipe
is normal, so graphify should exit 0 the way foo | head does.

Fix

Wrap the CLI entry point: catch BrokenPipeError and OSError with EINVAL or
EPIPE (Windows reports a closed pipe as EINVAL), redirect stdout to devnull
so the shutdown flush stays quiet, and exit 0. Unrelated OSErrors still
propagate, so real failures such as a missing graph.json are not masked.

Verification

A reader that reads one line then closes the pipe:

before: returncode=120, "Exception ignored on flushing sys.stdout"
after:  returncode=0,   clean

Adds tests/test_broken_pipe_exit.py (5 tests covering the exit-code contract,
including that non-pipe errors still propagate). Existing CLI suites pass.

[safishamsi]

Thanks @varuntej07 — this shipped as part of the #1807 fix in 0.9.14. Your explicit in-guard sys.stdout.flush() was the important nuance my first pass missed (block-buffered piped stdout only flushing at shutdown, outside the guard), so I adopted it in a46eee4 and credited you. Also handled the Windows OSError(EINVAL) form per your note. Really appreciate the well-reasoned PR.

[varuntej07]

Thanks for the review and the credit @safishamsi. Glad the explicit flush helped close that edge case cleanly. Appreciate you building Graphify, keep pushing! More tasks, fewer tokens!!