feat(scanner): derive skill/plugin source from install manifests

[SherlockSalvatore]

Closes #89.

Problem

scanner::detect_source infers an extension's source by walking up to the nearest enclosing .git. When an agent home (e.g. ~/.claude) is kept under the user's own dotfiles repo, everything beneath it — plugins cached in ~/.claude/plugins/cache/<marketplace>/..., skills, etc. — is mis-attributed to that backup remote, collapsing many unrelated sources into one bogus group. PR #88 fixed only the symlinked-skill slice; this addresses the root cause for skills and plugins.

Fix

Read each tool's own install manifest as the authoritative source; fall back to detect_source only when there is no manifest entry.

• Skills — override with <root>/.skill-lock.json (the skills CLI lockfile), matched by the on-disk folder name (how the CLI keys it), parsed once per lockfile and cached. A real git checkout's commit hash is preserved.
• Plugins — PluginEntry gains source_url; the Claude adapter fills it from plugins/known_marketplaces.json (github marketplaces → owner/repo); scan_plugins prefers it over the .git walk. Non-github marketplaces are skipped so we never fabricate a wrong URL. Other adapters pass None (behaviour unchanged).

Testing

• cargo test -p hk-core — 531 passed, incl. two new regression tests:
  • test_skill_lock_overrides_enclosing_git_source — the lockfile beats a populated enclosing repo; a sibling skill absent from the lock still falls back; the override matches by folder name even when frontmatter name differs.
  • test_scan_plugins_attributes_to_marketplace_repo — a plugin is attributed to its marketplace's upstream repo.
• cargo clippy -p hk-core — clean for the touched files.

Notes

• Stacked on fix(skills): attribute symlinked skills to real source, not enclosing repo #88 (builds on its canonicalize in scan_skill_dir). Until fix(skills): attribute symlinked skills to real source, not enclosing repo #88 merges this PR's range includes fix(skills): attribute symlinked skills to real source, not enclosing repo #88's commit; I'll rebase onto main once fix(skills): attribute symlinked skills to real source, not enclosing repo #88 lands.
• Deferred (kept surgical): Codex/Copilot also parse marketplace plugins and can adopt the same source_url resolution later; once manifest resolution is in, the store's git-source backfill can be narrowed.

Store self-heal (existing DBs)

The scanner change fixes attribution going forward, but on an existing DB the git-source backfill had already stamped install_url/pack from the old (wrong) source, and the backfill only runs on install_type IS NULL so it never refreshes them — and deriveExtensionUrl prefers install_url, so the corrected source_json.url stays shadowed.

refresh_stale_git_install_meta (parallel to #88's self-heal) realigns install_type='git' skill/plugin rows whose recorded owner/repo differs from the now-authoritative source_json.url owner/repo, clearing the stale branch/subpath + pack (re-derived by backfill_packs). It compares by pack, not raw URL string, so a legitimate install recorded as …/repo is not churned against the scanner's …/repo.git remote every sync (which would wipe its pinned revision/check state). Verified on a real polluted DB: 13 plugins re-attributed to their marketplaces, same-repo and self-authored skills left untouched.

Known properties / limitations

• Self-heal is a one-way DB write. refresh_stale_git_install_meta persists the realignment, so reverting the code does not roll the data back (the old backfill only fires on install_type IS NULL). In practice the only values it overwrites are ones whose owner/repo genuinely changed — i.e. stale pollution — and pack-gating leaves same-repo rows (incl. .git-suffix and case-only variants) untouched, so a legitimately pinned revision is not lost.
• Comparison is by owner/repo, host-insensitive. A repo that migrated host but kept the same owner/repo (e.g. gitlab→github) is treated as the same repo and not realigned; the stored URL keeps the old host. This is intentional (it's what avoids churning .git-suffix/case/scheme variants) and harmless for grouping, which keys on owner/repo.
• Non-github marketplaces are left to detect_source (no fabricated URL); plugins from such markets under a git-managed home stay mis-attributed. Tracked for follow-up in Derive extension source from the tool's install manifest, not the enclosing .git #89, alongside Codex's per-plugin manifest.

Known interactions

• Updating a manifest-sourced skill deploys over its on-disk copies. Once a skills-CLI-installed skill resolves to its real upstream, it becomes update-eligible, and the update path clones that repo and deploy_skills it over every same-named installed copy — including the canonical ~/.agents/skills/<name> that the external skills CLI manages (and any agent home symlinked to it). The files get updated but the CLI's .skill-lock.json hash/commit is not, so the two can drift. This is pre-existing behaviour (the marketplace-attributed sibling copies already triggered the same clone+deploy), widened here because the symlinked copy is now also an entry point. Flagged for maintainer awareness; not changed in this PR.

Decision for maintainer

This PR's blast radius is intentionally bounded: it changes attribution (and a one-time, idempotent, pack-gated DB realignment), and the one potentially destructive interaction — updating an externally-managed skill — is user-triggered (nothing happens until someone clicks Update) and pre-existing (marketplace-attributed copies already cloned + deployed over the same files). So it is safe to ship as-is.

What's left is a policy choice that should be yours, not silently encoded here: should HarnessKit offer Update/Delete on skills that an external tool (the skills CLI, tracked in ~/.agents/.skill-lock.json) manages? Now that those skills resolve to a real upstream, they become update-eligible, and deploy_skill writes through the agent-home symlink onto the CLI-managed ~/.agents/skills/<name>, leaving the CLI's lockfile hash stale.

Two directions, for you to pick before any further change:

• A — treat externally-managed (lockfile-present / symlinked) skills as read-only in HarnessKit: show source + Check-Updates info, but gate the destructive Update/Delete with a "managed by the skills CLI" notice. Minimal, safe, hands-off. (My recommendation.)
• B — full integration: HarnessKit writes back .skill-lock.json (or shells out to the skills CLI) after an update. Complete, but couples HarnessKit to the external tool's format and lifecycle.

This PR deliberately stays at attribution only. If you favour a direction, I'll do it as a separate follow-up (alongside a small, safe hardening: matching find_skill_in_repo by folder as well as name, so a skill whose frontmatter name differs from its repo folder still updates). Tracked with the manifest follow-ups in #89.

[RealZST]

Rebased onto main (resolves the #88-squash conflict). Two commits:

1. fix(store): only manifest-derived sources may correct an install record (432970e)

   refresh_stale_git_install_meta realigned install_url whenever the scanned source's pack differed — including a .git-inferred dotfiles repo (an HK-git-installed skill sitting under one), which clobbered the authoritative install_url and wiped its pinned revision. Added Source::from_manifest (true only for lockfile/marketplace sources) and gated the realignment on it.

2. feat(skills): delegate externally-managed skill updates to the skills CLI (099ad62)
   A/B decision → B, via shell-out (HK never touches .skill-lock.json).

   • A from_manifest skill update runs skills update <name> -g -y (→ npx --yes skills → HK's own clone+deploy as fallbacks). The CLI updates files and lockfile together, no drift.
   • Delete stays native: HK's delete is agent/path-granular; skills remove removes from every agent, and a per-agent symlink isn't the canonical copy.
   • HK records the upstream HEAD after a delegated update, else install_revision stays NULL (deployed files aren't a git checkout) and the row sticks on "update available".

Tested web + desktop.

Known limitation

Monorepo sources still update-check by repo HEAD, so every skill in a repo flags "update available" when any one of them changes. The CLI checks per-skill folder hash but has no read-only check command, so delegating the check would couple HK to its registry. The repo-level check over-reports but never hides a real update.