Kit manifest — extend a base kit hosted on GitHub or Git at a pinned ref

[Oleg67]

Kit manifest — extend a base kit hosted on GitHub or Git at a pinned ref

Part of #139. Depends on #180.

Context

#139 requires overlays to work for local and remote bases alike. The earlier slices deliberately use local paths, so the model, the merge and the install path can be settled without network behaviour in the tests. This slice adds the remote sources, reusing the resolution and caching kit installation already has: release and tag resolution for GitHub sources, clone-and-resolve for generic Git sources, and a cache keyed by resolved commit.

Scope

• [kits.extends] source accepts a GitHub source or a generic Git URL, resolved at the pinned ref through the same helpers cfs kit install uses, with the resolved commit recorded as the base's content identity.
• An unpinned base — latest, or anything that resolves to a moving target — is rejected before anything is written, so a resolution is always reproducible.
• The kit selector picks one kit out of a multi-kit base manifest, mirroring the selector syntax that already exists for Git sources.
• Tests stay network-free, using the existing fixtures for tarball and Git resolution.

Acceptance criteria

1. An overlay extending a GitHub-hosted base at a tag installs, and the resolved commit is recorded as the base's content identity.
2. An overlay extending a generic Git base at a pinned ref installs.
3. An unpinned base is rejected with a clear message and nothing is written.
4. A base manifest containing several kits resolves to the one named by the selector.
5. Portability holds: the same overlay works in register mode and copy mode, with local and remote bases.

Delivery

One PR, feat(kit): extend a base kit from GitHub or Git, closing this issue.