Detect servers started outside Jasper's environment and offer to restart them under Jasper

[ericwinger]

Closes #472.

The problem

Jasper runs its own gslist against the root it manages, and a GemStone server registers in the locks/ directory of whatever GEMSTONE_GLOBAL_DIR it was started with. A stone or NetLDI started by hand — from a shell whose GemStone environment differs from Jasper's — therefore registers somewhere Jasper does not look, and gslist alone reported it as Stopped while the process was plainly alive.

What the user hit:

• The Databases tree could show Stone Running / NetLDI Stopped with both processes up, because one had registered where Jasper looks and the other had not.
• The login failed as though nothing were running, and Jasper offered to start the database.
• Accepting that offer collided with the servers already holding those names.
• In some states a raw GEMSTONE environment variable is not defined — the GemStone shell script's own stderr, relayed verbatim — sent the user off to debug a shell profile and an install that were both fine.

What this does

Cross-checks the host process table against Jasper's own gslist and marks such a server Running outside Jasper, with its PID and registration directory in the row's tooltip. On connect — or from the row's new Restart Under Jasper's Environment action — Jasper offers to stop it and start it again under its own environment, worded as the environment mismatch it is rather than as a missing install.

The clean stopstone/stopnetldi runs against the directory the server actually registered in, which is what lets it stop cleanly instead of being killed; the force-kill sits behind that as a fallback.

Identity is the careful part. Two databases can share a stone name, so Jasper stops a server only when the conf/log paths that server was started with place it inside the managed database's directory. When it cannot confirm, it says so plainly and does not offer the restart. If a stop or kill fails it reports both names, the PIDs, the registration directory, the gslist invocation that will show the servers where they actually are, and the lock files a kill leaves behind — rather than dead-ending.

Folded in from the same investigation

• The tree no longer shows a healthy Running for a database a login cannot reach. Rows now distinguish Running, Stopped, not responding, not connectable (the stone is fine but nothing can traverse its NetLDI), and Running outside Jasper. classifyStartNeed leads with the same isConnectable predicate the tree derives its statuses from, so the two agree by construction rather than by coincidence.
• Discovery no longer inherits GEMSTONE_NRS_ALL from the shell that launched the editor, whose #dir: and #netldi: components can point somewhere other than what Jasper manages.
• deleteDatabase and replaceExtent could act under a live stone. Both gated on "appears in Jasper's gslist", which is false for an externally started stone even though that process has the extent open. Both now refuse for a stone alive anywhere on the host, and say what to do about it.
• "GemStone <version> not found. Please extract it first." now names the root Jasper searched and the directory it looked for, and points at both ways out.

Testing

npm run lint && npm run format:check && npm run compile && npm test all clean — 6,580 tests.

Mostly unit-level, with an integration test (externalServerScan.integration.test.ts) that runs the scan against a live stone and reproduces the bug end to end: the same servers and the same gslist binary, pointed at a different GEMSTONE_GLOBAL_DIR, report "no GemStone servers" while ps still sees them. It is in the CI matrix, so it runs against every release rather than one machine's install.

Several fixes came from a review pass on the first two commits; the third commit's message has the detail. Two worth knowing about because they were tests that could not fail: which stop binary each server kind gets was asserted nowhere (proved by swapping them and watching the suite stay green), and the substitution of the GEMSTONE-undefined message was uncovered.

What I could not verify

macOS. Two things:

1. ps -eo was Linux-only — on BSD/Darwin -e means "also show the environment", not "all processes", so that form lists only processes with a controlling terminal, which a detached stoned never has. This would have made the whole feature silently inert on every Mac. Now -A, which selects on both; verified equivalent to -e on Linux, but the Darwin half is reasoned from the flag semantics rather than tested.
2. macOS may not let ps eww read another process's environment at all. If it does not, the registration directory is always unknown there, identity stays unconfirmed, and Restart & Connect is never offered — only Connect as-is. Detection itself still works. The integration test asserts this loudly so a macOS runner reports it rather than degrading quietly.

Both are worth a few minutes on a Mac before this ships.

The UI itself. The reconcile dialog and the new tree states have not been driven in a real editor window — every branch of the flow is unit-tested, but nobody has looked at it.

Suggested review order

1. client/src/externalServerScan.ts — the parsing and identity rules, the load-bearing part
2. client/src/processManager.ts — getExternalServers, stopExternalServer, killHostServer
3. client/src/externalServerReconcile.ts — the decision flow and the wording
4. Everything else is wiring

🤖 Generated with Claude Code