cli + orchestrator: a second engine on one machine is not refused

[nathancrtr]

Outcome

A second gateline up on a machine where one is already running is refused, with a message that names the running one.

Why

The supported topology is one process per machine, with one engine in each dispatch repository. Nothing enforces it. A second gateline up --port N starts, and since #550 it puts a second engine in every repository the config lists as dispatch. Two engines over one repository are two authorities, which is the state docs/TOPOLOGY.md §3.1 exists to prevent. Their limits also double.

Each engine writes a health file under its repository's git directory, with a heartbeat time. That is enough to notice a live engine before starting another.

Work

• At startup, for each dispatch repository, read its health file. If the heartbeat is fresh and the process that wrote it is alive on this machine, refuse to start and name the repository and the process.
• A stale file, or one written by a process that is gone, does not block.
• The standalone gateline-orchestrator does the same check.
• Say in the refusal how to proceed when the check is wrong.

Also here

The standalone gateline-orchestrator passes its numeric flags through parseFloat unchecked. A value that is not a number becomes NaN, and a NaN spend limit or cap admits every dispatch. gateline up validates these since #550. The standalone binary should use the same checks.

Found in review of #550. Part of #492.