Lock-file design for lykn projects

[oubiwann]

Context

Per DD-51 Future Work: when lykn add lands (separate ticket),
lock-file semantics need designing. Lykn projects today have no
lock-file — version pinning is implicit in project.json
imports entries (jsr:@std/path@^1.0.0 resolves whatever Deno's
cache holds).

A lock-file would record the actual resolved versions so:

1. Reproducible builds across machines (same project.json →
   same exact deps).
2. CI/CD can verify lock-file matches project.json.
3. Audit trails for security tooling.

Open design questions

• File format and location — lykn.lock? project.lock.json?
  TOML, JSON, or other?
• Coexistence with deno.lock — does lykn generate its own or
  defer to Deno's?
• Update semantics — lykn add updates lock; lykn lock --update
  refreshes all?
• Commit-or-ignore default — most ecosystems commit; lykn should
  probably too.
• Verification — lykn check --lock or always-on at build time?

Scope

Substantial design pass before implementation. The implementation
itself is moderate (file I/O + version-comparison logic).

Target

Depends on lykn add (separate ticket). Naturally a fast-follow
to that work.

References

• DD-51 Future Work section
• M7 closing report fast-follow Source-map generation for compiled JS output (post-0.6.0) #4
• Prior art: Cargo.lock, package-lock.json, deno.lock