Reinstall @loopover/engine + @loopover/miner at real published versions on the AMS verification server (currently a hand-patched 3.1.1 + ancient 2.0.0)

[JSONbored]

Problem

The AMS self-host verification server's globally-installed AMS packages are badly out of sync with what's actually published and merged:

• @loopover/engine: package.json reports 3.1.1, but the installed dist/miner/cli-subprocess-driver.js has been hand-patched with the claude-cli driver's --permission-mode acceptEdits denies every Read/Bash call, silently blocking all real work #6840/fix(miner): grant the claude-cli driver Read/Bash access, not just edits #6856 fix on top of that old version (a locally-built tarball left over from a prior debugging session) — not the real, officially published 3.2.x release that fix actually shipped in.
• @loopover/miner: installed at 2.0.0. Latest published is 3.2.3 — a two-major-version gap.

Any AMS run on this server right now is testing an unversioned, hand-patched build that doesn't correspond to any real release, not the actual current state of the product.

Area

Infra / ops — this is a real server, not a GitHub-issue-shaped code change (per this repo's own "what's safe to unleash" test: live credential/deployment actions on a specific dedicated box are maintainer-executed ops, not contributor work).

Proposal

Reinstall both packages globally at their real latest published versions (npm install -g @loopover/engine@latest @loopover/miner@latest, or pin to the specific versions the maintainer wants to standardize on), removing the manually-patched dist files. Clean up the leftover debugging working directory afterward — it has stale build artifacts, diagnostic scripts, and old auth/credential artifacts from a prior session that shouldn't persist on the box; rotate/revoke any credentials found there before deleting, in case any of it is still live.

Once current, re-run the discover/plan/code loop against a real target to get a trustworthy signal — including specifically re-checking whether #6363-v2's target_not_found/issue_missing failure still reproduces on current code, since that's untracked and unconfirmed as a real bug vs. a version-staleness artifact.

Deliverables

• @loopover/engine and @loopover/miner reinstalled at real, officially published versions.
• Stale debugging artifacts cleaned up (credentials rotated first if live).
• A fresh, current-code pilot run's outcome recorded (even just as a comment here), specifically noting whether target_not_found/issue_missing still reproduces.

Resources

• claude-cli driver's --permission-mode acceptEdits denies every Read/Bash call, silently blocking all real work #6840 / fix(miner): grant the claude-cli driver Read/Bash access, not just edits #6856 (the fix that's hand-patched but not properly installed)
• fix(miner): forward HOME and the real coding-agent credential to CLI subprocesses #6901, fix(miner): grant Read/Bash in the agent-sdk driver's tool allowlist (#7245) #7276 (related fixes in the same release range)

Boundaries

Ops action on real infrastructure with real credentials — maintainer-only, not contributor-eligible. No server hostnames, usernames, file paths, or credential identifiers belong in this issue or its comments — this is a public repo.

maintainer-only — infra/ops, not a build task.

[linear-code]

JSO-5400

[JSONbored]

Done.

• `@loopover/engine` and `@loopover/miner` reinstalled globally at their real published versions (`3.5.0`/`3.5.0`, current latest as of tonight's release), replacing the hand-patched `3.1.1` dist and the two-major-version-stale `2.0.0` miner install. `loopover-miner doctor` now reports `engine-version-skew: ok`.
• The leftover debugging working directory contained two live credentials in plaintext (a GitHub OAuth token and a coding-agent OAuth token from a prior session). Both files were deleted immediately; the underlying grants still need revocation via the account that issued them (flagged out-of-band, not detailed here per this issue's own boundary). Remaining stale artifacts (old tarballs, attempt logs, diagnostic scripts) removed too.
• Pilot run against a real target (a currently-open, unrelated issue in this repo) via `discover` + `attempt --dry-run` on current code: target resolved cleanly, no `target_not_found`/`issue_missing`. That failure mode does not reproduce on current code — confirms it was a version-staleness artifact, not a real bug.

Closing.