fix: strip the fs-routes root deterministically via a required base option

[uhyo]

Closes #139

Problem

modulesToRouteFiles inferred the routes root as the longest common directory prefix of the import.meta.glob keys. When every page happened to live under one shared subdirectory, that subdirectory was treated as part of the routes root and stripped, shifting all routes up one level:

• {"./pages/blog/page.tsx", "./pages/blog/post/page.tsx"} → routes / and /post instead of /blog and /blog/post
• A single nested page {"./pages/docs/page.tsx"} → route / instead of /docs

Changes

• createFsRoutesEntries now takes a required base option — the routes directory the glob keys are relative to (e.g. "./pages"). The prefix is stripped deterministically; matching is lenient about a trailing slash and a missing ./.
• The plugin's fsRoutes mode passes its resolved routes directory (globBase) as base in the generated virtual:funstack/entries module, so plugin users are unaffected.
• The common-prefix heuristic is removed entirely. A base that does not prefix every globbed key now fails the build with a clear error instead of silently guessing the routes root.
• Unit tests cover both reproductions from the issue, the plugin's root-relative base form, the lenient matching, and the mismatch error.
• Docs: the File-System Routing page now documents base for direct createFsRoutesEntries users.

Requiring base is a breaking change for direct createFsRoutesEntries users, but the fs-routes module is experimental and not covered by semantic versioning.

Verification

• pnpm typecheck, pnpm test:run (81 tests), pnpm lint, pnpm format:check, pnpm build all pass
• fs-routing e2e suite (9 tests) passes against a production build

🤖 Generated with Claude Code

https://claude.ai/code/session_01EV5Pn6mAHVvqBZHjFKUguA

---

Generated by Claude Code