Seed an install tree from the store repo

#9 fixed this for tracker lanes: newgit tracker capture <name> --from-store seeds a lane from what is already in the working repo, instead of round-tripping through an instance. Install trees have no equivalent, so the first instance of a given key always pays a full install — even when a byte-identical tree already exists in the store repo.

Concretely: my first spawn ran npm ci while a matching node_modules sat in the main checkout. Same lockfile, same platform, same Node.

The store (from #50) is content-addressed on [identity] paths + key_command + the definition file, so seeding is "compute the key against the store repo's working tree, verify the produces paths exist and are relocatable, publish" — all steps that already exist, since publishing happens at the end of a normal prepare.

The asymmetry with #9 is what makes it feel like an omission rather than a decision.

Caveat worth deciding deliberately: the store repo's tree may be polluted in ways a fresh install is not (mine had 9 GB of Android build output in it — see #91), so a seed probably wants to be explicit (newgit resource seed deps) rather than automatic.

Environment: newgit 0.3.0 (fba8fa7090e2), macOS 15 (Darwin 25.6.0), APFS. npm-workspaces monorepo (Expo/React Native + Next.js + Supabase); local stack is Supabase CLI 2.107.0 (12 containers, Docker Desktop 28.2.2), Metro, and a Dockerised routing service. 4 instances spawned over one session; resources deps (install), expo (process), supabase (command-snapshot-migrations), r5 (project-owned).

Start by tracing the existing newgit tracker capture <name> --from-store flow and the publishing step at the end of a normal prepare. Compare that entry point with install-tree resources and the proposed newgit resource seed deps; done should include deliberate seeding, key verification, produces and relocatability checks, and publishing only a matching tree.