v0.1.4

Fixed

• A write to a helper that has already exited no longer throws an uncaught
  EPIPE. kill() (or write/resize) in the window between the helper's
  death and the close event wrote into a pipe whose reader was gone. Node
  reports that as an error event on the helper's stdin, which had no listener,
  so it was thrown from process.nextTick. In Electron that is the main-process
  "A JavaScript error occurred" dialog, a synchronous GTK dialog on the main
  thread: measured in Genie 2 on Linux, where a front-door Caddy that could not
  bind its port exited and Genie's immediate stop hit the window. Genie froze
  behind a dialog nobody could see.

  The helper's stdin now has an error listener. EPIPE and
  ERR_STREAM_DESTROYED mean the helper is gone, which close (or the Exit
  frame) already reports with what actually happened, so they are dropped. Any
  other stdin error goes to onError like every other fault (and to stderr when
  nobody listens, #1). Nothing is thrown. A caller observes no change except
  that the crash is gone.

  Test: src/__tests__/stdin-epipe.test.ts uses a helper that closes its stdin
  and stays alive, so the window is reproduced every run. Its control first shows
  that a plain write gets EPIPE; the check counts uncaught exceptions. It is red
  on 0.1.3 ([ 'write EPIPE' ]) and green with the fix, run in a Linux VM.

• A helper that cannot start now names fancy-pty and its path on every
  platform, not only on Windows. A non-executable helper is a synchronous
  throw on Windows (EFTYPE), which 0.1.0 already wrapped. On POSIX it is an
  error event (EACCES), and a missing path is ENOENT everywhere. Those arrived
  as a bare spawn EACCES naming neither the package nor the file. An error
  before the helper's spawn event is now worded "fancy-pty: could not start
  the helper at ()", with the original as cause. After spawn,
errors pass through unchanged. The test that covered this asserted only the
Windows half, so it was red on the Linux CI runner for 0.1.3. It now asserts
the same promise on every platform.

Added

• npm run verify:flash — a live Windows check that no console window ever
  APPEARS during a spawn/kill cycle (fancy-term-host #4), plus the probe it
  runs on. No consumer-visible change; this measures a claim that was previously
  only argued.

  The claim was architectural and sound — this package ships no agent process,
  so there is no second executable to pop a window the way node-pty's legacy
  ConPTY agent did. But fancy-term-host's 0.10.0-rc.1 notes said #4 was "in
  the Windows VM acceptance set" and "re-proved rather than assumed", and when
  that was checked against the acceptance record it was not there — the
  smoke covered the window and the helper was spawned with windowsHide, but
  nothing asserted "no console flashed" as its own control. A confident sentence
  stood in for a measurement.

  Measured now, on win32-x64, 8 spawn/kill cycles against 0.1.3: 8
  PseudoConsoleWindows created, 0 ever shown. The discriminator is the
  EVENT_OBJECT_SHOW, not the window — ConPTY creates one per pty regardless,
  so counting windows would have produced a false positive on correct code.

  --verify runs a positive control first and reports VOID rather than PASS
  if the probe cannot see a console it opened itself: a flash lasts tens of
  milliseconds, and an instrument that cannot catch one is indistinguishable
  from a package that never flashes. Proven to go red as well — a deliberately
  flashing subject gives 6 visible shows and exit 1.

  Known limit, stated rather than rounded off: this runs on an interactive
  desktop, while #4 appeared under the windowless detached service host.