getAdapter() reports static for an SSR app that prerenders any route

Summary

TanStackStart::getAdapter() returns static for any config containing a prerender key, including nitro-based SSR apps that prerender a route or two and still need a running server.

Cause

src/Detection/Framework/TanStackStart.php:

if (!\preg_match('/\bprerender\b/', $stripped) || \preg_match('/\bprerender[\x27\x22]?\s*:\s*false\b/', $stripped)) {
    return 'ssr';
}

return 'static';

The presence of the token decides the answer. Prerendering a subset of routes is a partial-prerender SSR setup, not a static export — the server entry is still emitted and still required.

Reproduction

Against 0.2.6:

Comment stripping works correctly; the issue is only the subset case.

Real repository affected

jackytea/tanstack-starter — vite.config.ts registers tanstackStart() alongside nitro({ ... prerender: { routes: ['/'], crawlLinks: true } }). Its build emits .output/server/index.mjs, so it is an SSR app, but getAdapter() reports static.

Possible direction

A prerender block only means static when it covers the whole site — roughly, crawlLinks with no filter/routes narrowing, or an explicit full-export preset. When a routes list or a filter is present, a server entry is still produced and ssr is the safer answer. Erring toward ssr also fails softer: a static site served by the SSR adapter still works, whereas an SSR app deployed as static loses its server.

Note this method appears to have no callers in Appwrite today, so there is no live impact there; it was found while testing detection behaviour against open-source repositories.

Start in src/Detection/Framework/TanStackStart.php and inspect TanStackStart::getAdapter(), focusing on how prerender configuration is classified. Reproduce the listed config cases, then update the behavior so narrowed routes or filters report ssr while full-site prerendering remains static, and verify the existing detection test suite.