fix: serialize each route view path once

[kavhnr]

Summary

• Serialize fields shared by the flat and nested views without path.
• Add the original manifest path once when the flat view is built.
• Keep the group-stripped, parent-relative path once in each pageRoutes object.
• Add a patch changeset and regression coverage for a three-level group route.

Root cause

The Vite adapter serialized each complete flat manifest entry into a shared binding. serializeTree spread that binding into a page route and then added the adjusted tree path. Thus, the spread first assigned the original flat path, and the explicit path field replaced it.

This shape is valid JavaScript. A minimal Vite 8 build, TypeScript, and esbuild accept it. The problem is an unwanted assignment in generated source, not a duplicate-key syntax error.

The shared binding now contains only fields common to both views. The flat route adds its original path, while the nested page route adds its adjusted path. This keeps route-group removal and parent-relative nesting. It also keeps IDs, children, module refs, and other nested values. The two views still share these non-path values.

Tests

The regression test inspects the generated shared bindings and evaluates the generated module. It covers:

• original paths in the flat manifest;
• a pathless group layout;
• group removal in pageRoutes;
• parent-relative paths through three levels;
• IDs and children;
• shared non-path data.

The test fails on base commit 4ff503f and passes with this change.

Validation with Node 24.15.0 and pnpm 11.1.1:

• pnpm install --frozen-lockfile — passed
• pnpm vitest run test/vite.spec.ts -t 'assigns each route view its own path once' — passed
• pnpm test — passed, 104 tests
• pnpm build — passed
• pnpm typecheck:dist — passed
• npm pack --dry-run — passed
• pnpm prettier --check src/vite/index.ts test/vite.spec.ts .changeset/clean-page-route-paths.md — passed
• packed package with Vite 8.2.2 — lazy and eager production builds passed

Fixes #10

[kavhnr]

Closing after further review. The existing generated code has correct runtime behavior and produces no verified compiler or build failure. This change would add route objects and spreads without a public behavior fix.