flue init scaffolds an unpinned hono range that splits from @flue/runtime's exact pin, breaking check:types on a fresh project

Describe the Bug

A freshly scaffolded project fails its own generated check:types script. flue init writes an unpinned hono range into the new project's package.json, while @flue/runtime pins hono to an exact version. npm resolves the two independently and installs two copies of hono, so Hono in the scaffolded src/app.ts and the Hono returned by createAgentRouter() are different interface types with the same name.

src/app.ts(13,28): error TS2741: Property 'query' is missing in type 'Hono<BlankEnv, BlankSchema, "/">' but required in type 'Hono<Env, Schema, string, string>'.

The mismatch is visible in the installed tree:

Relevant source, currently on main:

• packages/cli/src/lib/init.ts — DEPENDENCY_VERSIONS.hono = '^4.7.0', assigned via dependencies.hono = DEPENDENCY_VERSIONS.hono when opts.deploy is set.
• packages/runtime/package.json — "dependencies": { "hono": "4.12.32" }.

This looks like the same class of failure as #591 (closed as completed), but that fix covered the monorepo workspace rather than the scaffold template, so newly generated projects still hit it. #591 proposed pinning to 4.13.1; the runtime now depends on 4.12.32, so the two sides currently disagree in both directions (project floats upward, runtime is exact).

Expected Behavior

npm install && npm run check:types passes in a project that flue init just created, with no manual intervention.

Ideally the scaffold's hono range is derived from the runtime's own dependency rather than hardcoded, so the two cannot drift again. Pinning DEPENDENCY_VERSIONS.hono to the version @flue/runtime depends on would be the minimal fix.

Steps to Reproduce

1. npx @flue/[email protected] init my-app --target cloudflare --deploy
2. cd my-app && npm install
3. npm run check:types → fails with TS2741 in src/app.ts

Confirmation that the hono split is the cause: npm install [email protected] removes the nested copy and npm run check:types then passes with no other changes.

Environment: @flue/cli 2.1.0, npm 10.9.2, Node v24.14.0, Windows 11.

Note on scope: I reproduced this with --target cloudflare --deploy. Since init.ts assigns dependencies.hono whenever opts.deploy is true, regardless of target, --target node --deploy should be affected identically — I did not test that target separately.