fix(store): prune ghost rows left by disabling then deleting a skill

[tshi92]

The bug

Disable a skill in HarnessKit, then delete its folder outside the app. The row
never goes away — no number of rescans clears it — and the app keeps offering an
extension that no longer exists.

Worse, the one thing a user might try makes it lie. toggle_skill's enable arm
is if disabled_file.exists() { rename }; with the file gone the branch simply
does not run, the function returns Ok, and the caller flips enabled to true
anyway. No error, no toast — the list now shows an active skill backed by
nothing. (That also happens to be the only way to clear the row today: once
enabled is true the guard below stops protecting it and the next scan collects
it. Nobody would ever find that.)

Why the old guard missed it

stale_row_should_prune opened with:

if !enabled {
    return false;   // "disabled rows are intentionally absent from scans"
}

That premise does not hold for skills. Disabling one renames SKILL.md to
SKILL.md.disabled, and the scanner looks for both names and reports the
renamed file with enabled = false (scanner::scan_skill_dir). A disabled
skill that is still on disk is therefore in every scan and is never stale — the
guard never applies to it.

The only way a disabled skill reaches that guard is if SKILL.md.disabled is
gone too. Which is precisely when the row should be collected. The guard was
firing exclusively in the case it was meant to exclude.

The fix

Narrow it to rows whose disabled state the store alone holds — what
disabled_config marks:

if !enabled && has_disabled_config {
    return false;
}

Skills never set that field; disabling one leaves the bytes on disk under
another name, so there is nothing in the store to lose and they become
collectable. Rows that would lose their only copy stay exempt, and most of
them carry no install_meta, so nothing further down would have saved them.

This is the same predicate UPSERT_EXTENSION_SQL already uses to stop a scan
from overwriting enabled, so the store keeps one notion of "this row's state
is mine" instead of two that can drift apart.

A second, quieter bug

For a disabled skill the scanner deliberately records the enabled filename
in source_path so the row's id survives toggling. So
Path::new(source_path).exists() is false for every disabled skill, and the
"file is still there, this was just a scan gap" exemption never reached them —
they had no protection against a transient scan failure at all. source_still_on_disk
now checks the .disabled sibling too.

Scope

Only skills change behaviour. Nothing else newly qualifies for pruning.

Verification

Unit: stale_row_should_prune's truth table gained the disabled cases; the
ghost-row test covers a disabled skill deleted (collected) and a disabled skill
still present as .disabled (kept); the per-agent test gained a row carrying
disabled_config to pin the new column through that query's own SELECT list.
test_sync_preserves_disabled_extensions now sets disabled_config the way
manager::toggle_mcp does — it was passing on the blanket guard rather than on
the invariant it claims to assert.

On a real store, through the desktop app: a probe skill disabled, deleted from
disk, and cleared on the next focus-triggered scan — including a second row for
the same file reached through a symlinked agent skills directory. Of the 85
remaining disabled rows carrying a source path, every one still resolves on disk
and none were collected.

cargo test -p hk-core: 708 + 16 passing.