Harper auto-resolution silently tests the published npm package when the consumer doesn't declare harper

## What happened

Running `npm run test:integration -- integrationTests/server/v1-gateway.test.ts` locally in the harper core repo (without `HARPER_INTEGRATION_TEST_INSTALL_SCRIPT`, which only CI sets) silently ran the suite against **`harper@5.0.0` from the npm registry** instead of the repo's freshly built `dist/`. Every test failed with 404s/401s because the published binary predates the feature under test — nothing indicated the wrong binary was in play, and the misdiagnosis cost hours.

## Why

The README documents resolution step 3 as:

> Auto-resolved from a `harper` package installed as a **project dependency**

and `harper` is correctly declared as a `peerDependency` (`^5.0.0`) — but **npm ≥7 auto-installs peerDependencies**. A consumer that never declares harper (the core repo itself, or any component repo that forgot) still ends up with `harper@5.0.0` hoisted into its `node_modules`, and `getHarperScript` step 3 resolves it:

```
$ npm ls harper # in HarperFast/harper — which declares no harper dep
harper@5.2.0-beta.1
└─┬ @harperfast/integration-testing@0.6.2
└── harper@5.0.0 # npm auto-installed to satisfy the peer range
```

The auto-install defeats the documented "project dependency" intent, and step 4 (cwd/ancestor `dist/bin/harper.js` — the fallback that would find the local build) is never reached.

## Candidate fixes

1. **`peerDependenciesMeta: { harper: { optional: true } }`** (preferred): npm stops auto-installing the peer. Consumers that declare harper resolve exactly as documented; consumers that don't fall through to the cwd/ancestor `dist` fallback or get the existing clear "Harper CLI script not found" error telling them their options. Behavior change only for repos that were (likely unknowingly) leaning on the auto-installed registry copy.
2. **Prefer cwd/ancestor `dist/bin/harper.js` over `node_modules` when both exist** (swap steps 3↔4 precedence): fixes the harper source tree, and is a no-op for component repos (whose own `dist/` is not a harper build). Slightly riskier for unusual directory layouts.

Note that resolving step 3 "from the project instead of the harness module" does *not* fix this — npm hoists the auto-installed peer into the consumer's root `node_modules`, so a cwd-based resolve finds the same wrong copy.

Regardless of direction, observability for the resolution decision is being proposed separately (log the resolved path + warn when `node_modules/harper` wins while a cwd `dist/bin/harper.js` exists).

🤖 Filed with [Claude Code](https://claude.com/claude-code) on behalf of @heskew

Start by locating getHarperScript and the package manifest, then reproduce the documented integration test command without HARPER_INTEGRATION_TEST_INSTALL_SCRIPT. Trace which resolution branch selects the installed harper package and compare it with the local dist fallback. Done means an undeclared harper dependency no longer silently selects the published package, with the relevant integration behavior covered or clearly reported.

Written by the indexing model from the issue text.