#3728 Docs: extension fmt never writes deno.lock and warns on a stale one (swamp-club#3717)

swamp-club#3717 changes extension fmt and fmt --check, so the fmt section of content/manual/reference/extensions/publishing.md (## fmt, ### Output) is out of date once it ships.

What changed:

• fmt and fmt --check read the module graph with the lock read-only, as push and quality do since #3613. They never create a deno.lock, and never rewrite an existing one.
• On a lock that no longer matches deno.json or package.json, fmt still passes (exit codes unchanged). Each entry point the lock refused is formatted and linted alone, without the local modules it imports. fmt prints a WRN line naming the lock, the project file and the command push asks for: deno install --entrypoint followed by the entry points, run in the project directory.
• In --json, the check and fix objects gain an optional staleLockfiles array; each entry has lockPath, projectFile, projectDir, entryPoints and command. The field is absent when no lock is stale.

Suggested content: one paragraph under ## fmt saying fmt treats the lock as read-only, the WRN line as an example under ### Output, and staleLockfiles in the JSON description. The explanation page extension-trust.md may want one sentence that fmt joins push and quality in never rewriting the lock.

---

2026-10-22 (Seth): on hold for one dependency-trust docs update, done after #3630 (now including #3632) and #3662 ship. That update covers #3725, #3728 and those two issues.