v3.7.0: Bump version 3.7.0 (#99)

Bump version 3.7.0 after https://github.com/replit/ruspty/pull/98

v3.6.0: dont drop user fd until node reads a synthetic EOF (#93)

turns out https://github.com/replit/ruspty/pull/51 reduced the race rate
but did not eliminate it completely. we still see the data race bug very
rarely and it is exacerbated on high-numbers of repeats in the tests
and/or high nodejs event loop utilization

my old theory was:
- the user fd is O_NONBLOCK clear so any writes there should block until
its made its way into the 4kb intermediary buffer
- as a result, when the .wait returns, we know that the program output
has at least made it fully into the the user fd input buffer
- because we poll until `controller_inq == 0 && controller_outq == 0 &&
user_inq == 0 && user_outq == 0`, in theory we should never call the js
side exit code until theres truly nothing left in the pipe (i.e. the
readstream on the nodejs side has it in its own buffer)

HOWEVER, with some logging i saw a few cases where in fact
`controller_inq == 0 && controller_outq == 0 && user_inq == 0 &&
user_outq == 0`, the program had exited, yet the nodejs side still
missed some data

what i think is _actually_ happening is that
1. one of libuv's io threads reads the data from the controller side and
queues a data event on the stream
2. polling exits as now theres no more data in the queues we immediately
`drop(user_fd);` which [sets TTY_OTHER_CLOSED
synchronously](https://github.com/torvalds/linux/blob/4ff71af020ae59ae2d83b174646fc2ad9fcd4dc4/drivers/tty/pty.c#L66)
and we get an error event queued on the stream
3. if the nodejs event loop happens to read error before data, we emit
'end' and mark the data as read even though technically nodejs hasnt
processed the data event yet so we drop data :(

how we fix it:
1. axe poll_pty_fds_until_read
2. make Pty struct own user_fd and expose a method for the js side to
drop this fd when its done
3. when child.wait finishes, write a synthetic 'EOF' that is actually a
custom OSC terminal control sequence (`\x1B]7878\x1B\\`, 7878 is RUST on
the phonepad :)) to the user fd (a cursory search shows no results, it
seems _very_ unlikely for this sequence to appear randomly)
4. on the nodejs wrapper side, create a transform stream that parses out
the synthetic EOF and emits it as a custom event when it happens
5. when the nodejs side hits this EOF, we know we are actually at the
end of the data stream and can safely drop user_fd

node-pty had the [same
problem](https://github.com/microsoft/node-pty/issues/72) and did the
:grug: brain thing and [added a wait
250ms](https://github.com/microsoft/vscode/commit/9464b54f39d8db943ddd4c134d9bef835b7bd506
) so im calling it slightly more ok

v3.5.3: handle ESRCH in more ptrace callsites (#91)

we are seeing processes exit with the following:

```
run process: run_parent03:44
Caused by:03:44
    0: handle_syscall pid=11203:44
    1: get_target_path03:44
    2: ptrace::getregs03:44
    3: ESRCH: No such process
```

a traced process can exit at any time so any ptrace calls that operate
on the pid must check esrch to see if the traced process has exited and
handle it appropriately

we already do it in a bunch of places but do it in more

v3.5.2

Bump version 3.5.2 (#88)

v3.5.1

bump to 3.5.1 (#86)

v3.5.0: bump version 3.5.0 (#84)

* Add `exclude_prefixes` to SandboxRule and Rule

v3.4.16

bump version 3.4.16 (#82)

v3.4.15: [safe-vibe-coding] Allow the AppArmor transition to fail (#79)

During the intermediate period, we want the AppArmor profile transition
to sometimes fail.

This change makes it possible for the process to continue even if the
transition fails instead of breaking everything.

v3.4.14: [safe-vibe-coding] Support changing the AppArmor profile (#78)

It'd be fun to experiment with adding more robust sandboxing techniques.

This change allows the caller to specify an AppArmor profile, if
supported.

v3.4.13: [safe-vibe-coding] Fix one panic (#77)

There was one stray `.unwrap()` in the codebase.