fix: derive install targets from the lockfile entry

[sametcelikbicak]

Closes #407. Closes #346.

A lockfile entry's agents list is the record of where a skill lives. Two callers guessed instead, and both put skills somewhere the record did not name:

• ci hardcoded targets: ['agents'] (src/api/ci.js:23) and never read entry.agents. A skill recorded as ['claude-code'] was reinstalled into ~/.agents/skills, the directory twelve agents share — so the skill ended up in two places and the lockfile disagreed with the disk.
• update never read entry.agents at all; detectTargets scanned the filesystem with existsSync. Every alias whose directory happened to hold the skill became its own target, so ~/.agents/skills was written once per alias, and a project-scoped agent produced a global lock entry.

Both now go through targetsFromLockEntry in src/utils/lockfile.js, which reproduces the recorded install and collapses aliases by directory. That dedupe rule was already in api/install.js:40-49 — this extends the existing rule rather than inventing one.

update keeps a filesystem scan as the fallback for entries predating the agents field; that fallback is now deduped too.

Also switches installer.js to resolveAgent from getAgentByFlag. getAgentByFlag('claude-code') returns nothing (the flag is claude), so installSkill hit return null and silently dropped the target — which is why the first version of the ci test still failed after targets were derived correctly. resolveAgent was added for exactly this by #416.

Verified end to end:

#407 allPassed: true | target: ~/.claude/skills/claudeonly
#346 targets: ["project"] | kurulum sayisi: 1   global lock: []

Two existing assertions encoded the old behaviour and were updated: a project-locked skill expecting targets: ['agents'], and a test asserting a codex label for the shared directory (reported once, as agents — the directory is identical).