Stop quit[] from ending the host process

[HugoFara]

Closes#160. quit sits in the script command table, so it is reachable from the Python binding and from the HTTP server, and it called exit(0).

Running the reproduction from the issue, before and after:

before quit[] before quit[]
<process gone> AFTER quit[]
FINALLY ran
still alive, exiting normally
ATEXIT ran

All four failures in one line of code: no exception to catch, finally and atexit skipped, buffered output lost — the left column does not even show before quit[] without an explicit flush=True, because exit() flushes C streams and not Python's io layer — and a status of 0, so a batch job records success having stopped early.

What changed

quit releases the session and records the request. Command::quitRequested() exposes it, Command::clearQuitRequest() forgets it. A shell stops when it sees it; an embedder is free to ignore it and carry on, which is the difference between asking and terminating.

The shell in app/forefire is what leaves now. Both the interactive loop and the HTTP listen loop check, so a quit[] served over HTTP still stops the server — that would otherwise have been functionality removed rather than fixed. executeLoop stops reading a script after one instead of the process vanishing mid-file.

Two things found while fixing it

currentSession.params was being deleted, and it is the singleton.quit did delete currentSession.params, which is SimulationParameters::GetInstance() — shared with every other holder and owned by the function-local static. It went unnoticed only because exit() came on the next line. Without the exit it is a use-after-free on the next parameter read, so removing the exit without removing this delete would have traded one bug for a worse one. It is no longer deleted.

The first version of my test passed with the bug still in place. A suite whose process calls exit(0) mid-run reports as a pass: ctest sees status 0, and the doctest summary that never printed is not something it checks for. The CTest entries now require doctest's closing Status: SUCCESS! line, which turns an early exit into a failure. Negative control, with exit(0) restored:

The following tests FAILED:
5 - unit.quit_command (Failed)

That property is worth having for every suite, not just this one, so it is applied to all five.

The safe topology path — @filippi, this is the part for you

Command.cpp:1125 called quit() from a catch (...) in the atmospheric step loop, under // TODO supersafe mode ?. So an internal failure ended the host process on its own, with status 0.

It now reports and returns error. This changes behaviour in coupled runs: where a safe-topology failure previously terminated, it now returns an error and the caller continues. That is the correct shape for a library, but it is your path and the call is yours — if a hard stop needs to stay reachable there, say so and I will make it a distinct command the binding does not expose, as #160 suggests.

The message also moves to stderr and is no longer gated on commandOutputs. ExecuteCommand discards command return values today, so a returned error that is also silent would be strictly worse than what it replaces.

Making ExecuteCommand propagate status is the obvious follow-up and is not attempted here — it changes a signature used by the CLI, CLibForeFire, EventCommand and the binding.

Verification

• Reproduction from Command::quit calls exit(0) from inside the library, silently killing the host process #160: passes, output above.
• Unit suite: 5/5, including three new cases.
• Negative control: restoring exit(0) fails unit.quit_command.
• runff: KML and NetCDF both match the references within tolerance.

---

This pull request, including its code changes and this description, was generated by Claude Opus 5, and reviewed manually before submitting.