docs/EXTENSIONS.md still documents the retired npm-resolution path as init --with's current behavior #531

What's wrong

`docs/EXTENSIONS.md`'s "Scaffolding with `init --with`" section (lines ~322-406) still describes the retired npm-resolution behavior as current for `--with` itself:

• Lines ~327-332: "at run time it resolves `@jimhoyd/urlcode-` for each name with Node's package resolution... Install a compatible package set there... before using `--with ui,auth`"
• Line ~382: "A name that is not installed refuses with the `npm install` command"
• Lines ~336-341: the documented `ScaffoldRequest` interface is missing the `acknowledgements` and `distribution` fields that `packages/core/src/init-with.ts:194` actually sends.

The correct bundle-only behavior (resolving `extension-bundles@v` from GitHub Releases, no npm involved) is only described later in the "Recorded versions" and "Signed executable extension bundles" sections, so a reader following the doc top-to-bottom gets the wrong mental model of `--with` before reaching the truth.

This is a direct instance of AGENTS.md's rule: "A code change that alters behavior a reader depends on is not finished until the matching page in `docs/` is updated" -- the bundle-only hard rule (PR #526) landed without a docs update, since it was scoped as a runtime/test change.

Note: this is about `--with` specifically. The standalone quickstart CLIs (`urlcode-auth init`, `urlcode-admin init`) are unaffected and still legitimately npm-based -- their docs should NOT change.

Also missing

No CHANGELOG.md or MIGRATION.md in `docs/` flags this as a behavior change for existing users who previously relied on `--with`'s npm-mode fallback.

Suggested fix

Rewrite the "Scaffolding with `init --with`" section to describe bundle resolution as the (only) current behavior, update the `ScaffoldRequest` interface snippet to match `packages/core/src/extensions.ts`, and consider a short changelog/migration note for the behavior change.