Provide guidance on deno.lock file management

Problem Statement

When swamp initializes a repository with extension models, a deno.lock file is generated in the project root. There is no guidance on whether this file should be:

1. Checked into version control or added to .gitignore
2. Located in the project root or scoped under .swamp/ like other swamp runtime artifacts

This creates uncertainty for users setting up swamp in their repos. The .gitignore entries added by swamp init cover .swamp/data/, .swamp/outputs/, .swamp/secrets/, etc., but say nothing about deno.lock.

Proposed Solution

Provide clear guidance on deno.lock management. Options to consider:

• If it should be committed: Document this in swamp init output or in the generated .gitignore comments (e.g., # Keep deno.lock checked in for reproducible builds)
• If it should be ignored: Add deno.lock to the .gitignore entries that swamp init generates
• If it should live under .swamp/: Move the lockfile scope so it's generated inside .swamp/ rather than polluting the project root, consistent with how other swamp artifacts are organized

Alternatives Considered

• Users could decide on their own, but this leads to inconsistency across teams and projects
• A note in swamp documentation would help, but inline guidance during swamp init would be more discoverable

Additional Context

The lockfile currently tracks JSR/npm dependencies used by extension models (e.g., @std/yaml, zod). For application repos (not libraries), committing the lockfile is generally recommended for reproducibility, but the root-level placement feels out of place when swamp otherwise keeps its artifacts under .swamp/.