CreateJobObjectA / SetInformationJobObject / AssignProcessToJobObject
were called inside the per-start thread and their return values were
ignored. Two consequences:
1. Each server crash-restart created a fresh kernel JobObject HANDLE
that was never CloseHandle'd. The HANDLE went out of scope when the
spawned thread exited, leaking a kernel object every crash.
2. On Win 7/8 (single-job systems) and inside parent jobs that disallow
breakaway, AssignProcessToJobObject silently failed, so
stremio-runtime could survive the shell's death and hold port 11470.
Hoist the setup into ensure_parent_job_object() guarded by sync::Once
so it runs exactly once per shell process, and check each return value
explicitly with a clear log message when the OS-level safety net is
degraded. The HANDLE is intentionally not closed: closing it while
KILL_ON_JOB_CLOSE is set would terminate the shell itself.
Closes#47Closes#48
stdout.read(...).unwrap_or(!0) substituted usize::MAX on Err, then
`if on > buffer.len() { continue; }` swallowed it and looped back into
read(). On a sticky IO error (broken pipe, EBADF) the thread spun a
CPU core forever and the accumulated logs were never flushed.
Match Ok(0)/Ok(n)/Err(e) explicitly: break on EOF, break on error after
logging, and treat any other Ok(n) as bytes read. Same change for
stderr.
Closes#51
