Offer a lockfile for --skip-install scaffolds (default scaffolds already commit pnpm-lock.yaml)

## Context

Split out from #387 (item 2.2 of the status audit there). Generated projects ship no lockfile — neither `pnpm-lock.yaml` nor `package-lock.json` — so every fresh scaffold resolves its dependency tree from scratch at install time.

## Why it matters

This is the mechanism behind the dependency-drift class of breakage (#398, the `@x402/evm` unmet-peer failure; the thirdweb chain variant in #400): templates with caret ranges resolve to whatever the ecosystem serves that day, and a scaffold that built yesterday can fail today with no repo change. The ai-chat template's original bug report also included `npm install` exiting 1 on peer-graph conflicts that a lockfile would have pinned away.

## Decision needed

1. **Ship lockfiles with the templates** — reproducible scaffolds, but N lockfiles to maintain (one per template × package-manager choice), and they go stale/conflict with the `.hbs` conditional dependency blocks.
2. **Generate a lockfile at scaffold time** — the CLI already runs `pnpm install` unless `--skip-install`; committing the resulting lockfile in the generated project's initial commit costs nothing and freezes the working resolution the user actually installed. (Likely the cheapest meaningful improvement.)
3. **Status quo + tighter pins** — accept drift but keep floors current (the #450 approach).

Option 2 appears to be nearly free: the initial git commit happens after `pnpm install` in `project-generator.ts`, so the lockfile may already be included when install isn't skipped — worth verifying, and if so this issue reduces to documenting that `--skip-install` scaffolds are unpinned.