lykn cache: lykn-fronted wrapper around deno cache (optional)

[oubiwann]

Context

Per DD-51 Future Work: lykn projects currently use deno cache <spec>
directly for offline prefetch. DD-51 explicitly accepts this as
non-banned (DD-51 Rule 3 — deno cache is acceptable
infrastructure tooling). However, for consistency with the
"lykn is the front door" principle (philosophy doc Principle 2),
a lykn cache wrapper could be added.

Question: is the wrapper worth adding? Trade-offs:

For:

• Consistency with lykn build, lykn test, lykn run, lykn publish, and (eventual) lykn add.
• Auto-discovery of project's imports — lykn cache could prefetch
  all entries from project.json imports without user typing each
  specifier.
• Future evolution path — wrapper could add lykn-specific behavior
  (like checking lock-file consistency).

Against:

• deno cache already works fine; adding a wrapper is busy-work.
• Maintenance burden — keeping the wrapper in sync with Deno's
  cache semantics as Deno evolves.
• "Just use deno cache" is a defensible answer.

Open design questions (if accepted)

• Auto-prefetch all imports vs. specific spec?
• Verify lock-file consistency post-cache?

Scope

Small if accepted. Could be a single-iteration milestone.

Target

Post-lykn add (so the design tradeoffs are clearer once the
"lykn-fronted dependency lifecycle" picture is more complete).

References

• DD-51 Future Work section
• M7 closing report fast-follow DD-50 Rule 2: replace runtime-throw stand-in with analysis-pass diagnostic #3