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

## 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 #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](https://claude.com/claude-code)