fix(fspy): bundle osh with the RunProcess getpgid ESRCH fix

[lifeiscontent]

Motivation

Fixes #702.

Cached tasks on macOS run under the bundled osh (fspy substitutes it for /bin/sh, which as a platform binary can't load DYLD_INSERT_LIBRARIES). Stock oils 0.37.0 resolves the child's pgid with getpgid() right after fork, before waiting on it — and on macOS getpgid() of an already-exited child fails with ESRCH. The shell dies with oils I/O error (main): No such process, exit 2, empty stdout. Under CPU contention (parallel test runs) a few percent of spawns die this way.

Upstream fix: oils-for-unix/oils#2689 — the pgid feeds MaybeGiveTerminal(), which already no-ops when job control is disabled, so the `getpgid()) is gated on job control being enabled and batch shells never pay the race.

Changes

• crates/fspy/build.rs downloads a 0.37.0 + patch build from https://github.com/lifeiscontent/oils-for-unix-build/releases/tag/oils-for-unix-0.37.0-fspy.1 (built by that repo's release workflow from the stock tarball plus patches/0001-run-process-esrch.patch, with build provenance attestations) until an upstream oils release carries the fix. If voidzero wants the binary under its own hosting, rebuilding from that repo's workflow and swapping the two URLs and hashes is the whole change.
• crates/fspy/tests/oils_esrch.rs runs 200 tracked shells through fast external commands under contention; it fails against the stock binary and passes against the patched one.

[lifeiscontent]

Upstream landed the fix: oils-for-unix/oils@f5bd5d9

It's the same change this PR bundles. The and self.job_control.Enabled() guard went in as written; Andy only reworded the comments and dropped a unicode char their Python build didn't like.

That doesn't unblock anything on its own, though. No oils release carries it yet, and Andy's note was "No guarantees on when the next release is ... but we are overdue for one." So this still needs the patched 0.37.0 build as it stands. Once a release ships, the cleanup is two URLs and two hashes in crates/fspy/build.rs pointed back at a stock build, and the fork goes away.

He also offered a tarball straight from oils CI. I'd rather not use that one. It's a job artifact built from main rather than a release, so we'd be trading a pinned 0.37.0-plus-one-patch for an unpinned snapshot with unrelated changes, behind a URL that won't stay put.

One other thing. CI, Security Analysis and fspy benchmark are all sitting in action_required, so nothing but Socket has actually run on this branch. Could someone approve the workflow runs? #701 is in the same state.