Tests: integration coverage for startHarper/teardownHarper against a real Harper

[heskew]

Summary

Follow-up from #8 / #9. The new test/ suite covers runHarperCommand, killHarper, and the port helpers in isolation, but the lifecycle orchestration (startHarper / teardownHarper) is not exercised end-to-end because that needs a real Harper instance (the package's harper peer dependency) and loopback-pool setup. Worth adding as a separate integration-test layer.

Coverage to add

• Happy path — startHarper(ctx) → make a request against ctx.harper.httpURL/operationsAPIURL → teardownHarper(ctx); assert the instance came up and was cleaned up.
• Teardown orchestration — teardownHarper kills the process, waits for the fixed ports to free, releases the loopback address back to the pool, and removes the data root dir.
• Race 2 restart path — killHarper(ctx) followed by startHarper(ctx) reusing the same hostname succeeds without EADDRINUSE (verifies the port-wait-before-spawn added in fix: idle-based startup readiness and port-safe teardown recycle #9).
• setupHarperWithFixture — a pre-installed component is available on first boot.

Notes

Needs a real Harper available (peer dependency) and the loopback pool configured (harper-integration-test-setup-loopback), so this likely lives in a separate harness from the fixture-based unit tests in test/. May be best run only where a Harper build is present (and skipped otherwise).

---

🤖 Generated with Claude Code