fix(daemon): remove a placed session's skills left at its session directory

[zfy0701]

Problem

#2801 moved a placed session's skill installs from the session directory into its checkout and gave
them a ledger key of their own. Bundles an earlier daemon had installed at the session directory stayed
there under the old key, which no code path reads again. A skill revoked or removed afterwards was
therefore never deleted from disk. No runtime scans that directory, but the model can still find the
files by searching the disk.

Change

• reconcileClusterSkills: after installing into the cwd, retireShimRootSkills reconciles the ledger
  under the executor's reported incarnation to no sources, through the bare skills client (the shim's
  own root). It runs only while that ledger still holds roots, so once it is empty later preparations
  only pay a local store read.
• A failed retirement is logged and retried at the next preparation; it never fails the launch.
• cwdSkillRequester's doc comment and one test comment condensed to one line, per the repository's
  comment rule.

Tests

• daemon-lifecycle.test.ts › "installs a placed session's skills into its checkout and retires those
  at its session directory". It drives runAgentWorkspacePreparation for a placed session and checks:
  • the install goes through the cwd client under the cwd ledger key, and the ledger roots are excluded
  • the old ledger is reconciled to nothing through the bare client
  • a failed retirement still returns the cwd and is retried, and an empty ledger is not touched again
• git-exclude.test.ts: the placed-session exclude test now fails if the filesystem is resolved without
  the session's path, which would have reached the holder's own disk.
• Affected suites (daemon lifecycle, git-exclude, executor plane, cluster skill coordinator): 154 passed.
  Daemon typecheck clean; eslint shows only the 2 warnings already on main; prettier clean.

Not in this PR

From the #2801 review, deliberately left out:

• Writing the exclude entry when the skills step fails partway. A failed preparation does not launch
  the session, so nothing commits the bundles, and the next successful preparation writes the entry.
  Until then the retention sweep only keeps the checkout, which is the safe outcome.
• Keying the cwd ledger on the checkout's identity rather than its path. A re-clone that tracks a
  path matching a prior root would conflict with an empty ledger too.

Refs #2801

🤖 Generated with Claude Code . Claude Opus 5.5

[agentconnect-md-test]

Reviewed revision 22619e27 in the verified merge checkout. No blocking findings. The cleanup targets the old session-directory ledger through the bare shim client, retains the existing authority and launch fences, and retries failed retirement without failing workspace preparation.

git diff --check passed. I could not rerun the focused suites: this checkout has no installed dependencies and pnpm is unavailable in the runner.

_{sent by review-bot (Codex · gpt-6-astra) · open in session}