lykn add: ergonomic dependency-addition command

[oubiwann]

Context

Per DD-51 Rule 4: Lykn projects use project.json workspace-level
imports, not Deno's per-package deno.json mechanism. deno add
is banned in lykn projects (writes to the wrong file). The user-
facing replacement is to edit project.json manually — which
works but lacks version resolution from JSR/npm.

lykn add would close the ergonomic gap with a Lykn-fronted
command:

lykn add @std/path        # adds latest from JSR
lykn add jsr:@std/path@^1 # adds with explicit version constraint
lykn add npm:lodash       # adds latest from npm

The command would:

1. Resolve the version (via deno info or equivalent).
2. Write the entry to project.json imports.
3. Optionally run deno cache <spec> to populate the cache.

Open design questions

• Version resolution strategy — track JSR's resolution semantics or
  use a simpler "latest with caret" default?
• Lock-file integration — depends on lock-file design (separate
  ticket).
• Interaction with deno cache — auto-prefetch or opt-in?
• Output format — show what was added; offer dry-run?

Files

• crates/lykn-cli/ — new add subcommand.
• Plus version-resolution helpers — possibly via deno subprocess
  similar to the V-08 import-macros work in crates/lykn-lang/src/expander/deno.rs.

Scope

Medium-large. Includes design + implementation + tests + docs
updates (guide 14 ID-07's manual-edit instruction becomes optional
once lykn add exists; SKILL.md Principle 1 bypass-table entry
becomes "prefer lykn add, edit project.json directly if
needed").

Target

0.6.x or later.

References

• DD-51 Rule 4: docs/design/01-draft/0051-deno-native-tool-boundaries-deno-add-deno-task-deno-cache-lykn-add.md
• M7 closing report fast-follow Rust expander: support (surface-macros "*.js") JS-loading directives #2