Nothing replaced dumpdata: consider an M2 compute process over pipes

Nobody has claimed this yet.

This issue was triaged from [`bugs/dan/0-M2-compute-process`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/0-M2-compute-process), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.

### The original file, verbatim

```text
now that dumpdata/loaddata no longer work anywhere, we might replace it
as follows:

start an M2 process and pause waiting for messages over a pair of pipes
accept a start message and fork
in the child accept further command line arguments and
process them, returning the output, exiting when done
repeat
```

### Where it stands today

`dumpdata`/`loaddata` were removed in `d560e8284a` (2019), and nothing replaced them. There is no
fork server, no daemon mode, and no persistent-process mechanism of any kind, so every invocation of
M2 pays full startup — which is precisely the cost the proposal was meant to amortize.

### What the file proposes

A small protocol rather than a rewrite: one M2 process waits on a pair of pipes, forks on a start
message, and lets the child take further arguments, return output and exit, while the parent stays
warm for the next request.

### Why it still matters

Anything that runs M2 many times in short succession pays the startup cost every time: the test
suite, documentation example capture, editor integrations, and web front ends. `dumpdata` used to
address this by saving an initialized image; with it gone the cost is unamortized.

### Notes for whoever picks this up

The fork-based design in the file interacts with two things worth checking first: whether the
Boehm collector and the engine tolerate `fork` in a process that has already initialized them, and
what happens to open files and sockets in the child. There is prior discussion of sandboxing M2
processes generally that touches the same territory.

_{`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)}

Start with bugs/dan/0-M2-compute-process and review the prior sandboxing discussion. Check whether the Boehm collector and engine tolerate fork after initialization, and inspect how open files and sockets behave in the child. Done means a defined replacement for dumpdata/loaddata that supports the proposed persistent process protocol.

Written by the indexing model from the issue text.