Let one polymake process serve the whole session

[fingolfin]

Stacked on #29.

Where the time actually goes

I claimed earlier that --config-path "" was most of the per-call overhead.
That was read from the polymake source and never measured, and it is wrong:

	per call
bare startup, no rules loaded	0.12 s
load a Polytope, --config-path ""	0.85 s
load a Polytope, the user's own config	0.80 s
load a Polytope, a private config we create	0.82 s

Config accounts for ~40 ms. The other ~0.7 s is loading the rules of an
application, and it is paid whatever the config path is. A per-session config
directory -- --config-path user=DIR, the writable form -- buys about 4%.

So the only way to stop paying it is to stop restarting polymake.

What this does

polymake - reads instructions from standard input, so polymaking now keeps
one such process per session and asks it to evaluate each call, driven through
InputOutputLocalProcess (in GAP core since 4.7.8, so no new dependency).

Results still go to a file, exactly as in #29, so the pipe only ever
carries a marker line. That is the design point that makes this simple: there
is no framing protocol to get wrong, and no chance of a large result filling
the pipe buffer and deadlocking.

pm.pl gained two entry points, polymaking_setup and polymaking_eval, and
calls them itself when given arguments. One-shot mode is therefore unchanged,
and stays the fallback whenever the process cannot be started or has died.

Measured

session	one process	one per call
10 calls	2.6 s	9.8 s	3.8x
40 calls	3.5 s	36.0 s	10.3x
hapcryst's test suite, unmodified	5.1 s	19.1 s	3.7x

Marginal cost of a call: ~29 ms rather than ~870 ms.

Things that had to be got right

• Repeated preferences. In a long lived process, adding the same rule
  preference again makes polymake warn_print that one is already in effect --
  once per call, into the captured stderr. They are now applied once per
  application.
• load resolves differently. Under --script a bare load($file) works;
  in shell mode it does not, and User::load is undefined. Fully qualified as
  Polymake::User::load.
• Closed streams raise. WriteLine on a closed stream errors rather than
  returning fail, so the retry never fired. The whole exchange is now guarded
  and a polymake that has gone away is replaced rather than reported.
• Lifecycle. The stream cannot survive into another session, so it is
  dropped after restoring a workspace (the same concern as CreatePolymakeObject(); fails the second time when using GAP workspace files #17) and closed at
  exit.
• Quoting. Filenames, keywords and preference strings are escaped before
  they are interpolated into perl string literals.

Testing

• Full suite: 0 failures in 5 files.
• New tst/persistent.tst checks that both modes give identical answers for
  the same object, that the process starts only when wanted, that killing it
  mid-session is recovered from transparently, and the quoting helpers.
• hapcryst: 0 failures, unmodified, in both modes.

Set PolymakePersistent to false for the old behaviour.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 90.29851% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.03%. Comparing base (702efbb) to head (c18663c).

Files with missing lines	Patch %	Lines
lib/environment.gi	89.43%	13 Missing ⚠️

Additional details and impacted files

@@                Coverage Diff                @@
##           polymake-json      #31      +/-   ##
=================================================
+ Coverage          83.44%   85.03%   +1.59%     
=================================================
  Files                 11       11              
  Lines                767      889     +122     
=================================================
+ Hits                 640      756     +116     
- Misses               127      133       +6     

Files with missing lines	Coverage Δ
lib/userpref.gi	83.57% <100.00%> (+1.40%)	⬆️
lib/environment.gi	89.62% <89.43%> (+0.51%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.