fix: monorepo workspace detection on Windows + OpenAPI route support

[adutton]

Summary

Fixes monorepo workspace detection failing on Windows and adds support for @hono/zod-openapi route patterns. Tested against a real pnpm monorepo with SvelteKit + Hono + Drizzle that was detected as raw-http with 1 route — now correctly detects sveltekit, hono | drizzle | typescript with 141 routes.

Scanner fixes (scanner.ts)

• Direct workspace paths not recognized — workspace patterns like app or api (without globs) were treated as parent directories to enumerate, so they were never registered as workspaces. Only glob patterns like packages/* worked.
• Windows \r in YAML parsing — pnpm-workspace.yaml with \r\n line endings produced paths like api\r, causing all package.json reads to silently fail and every workspace to fall back to raw-http.
• raw-http fallback not cleaned up — the root package.json fallback persisted even after real frameworks were aggregated from workspaces.

Route detection fixes (routes.ts, extract-routes.ts)

• createRoute() + .openapi() pattern — added AST support for the @hono/zod-openapi pattern where routes are defined via createRoute({ method, path }) and registered with .openapi(route, handler). Handles both inline calls and variable references.
• Monorepo entry points missing from prefix scan — resolveRoutePrefixes only checked root-level entry files. Workspace entry points like api/src/app.ts are now included, so .route('/prefix', router) mounts are discovered.
• Windows path separator mismatch in prefix map — prefix map keys used forward slashes but route.file used backslashes, preventing prefix application on Windows.

Test plan

• All 27 existing tests pass
• Verify against a pnpm monorepo with direct workspace paths (not just globs)
• Verify on Windows with \r\n line endings in pnpm-workspace.yaml
• Verify @hono/zod-openapi createRoute() routes are detected