Keep a lockfile-less site with a root index.html off the Node SDK

[Ref34t]

Found while looking at #870. It isn't the discoverability problem that issue reports — PostHog/posthog.com#18390 covers that — it's a separate defect in the same corner of detection.

Problem

javascript_web requires a committed lockfile. javascript_node matches any package.json. So a browser-only project whose lockfile isn't committed falls past the web integration and gets picked up by the Node one.

Reproducing against detectFramework on main:

Project	Detected
index.html + package.json + lockfile	javascript_web
index.html + package.json, no lockfile	javascript_node

In the second case the run installs posthog-node and instruments a server that doesn't exist. Nothing errors, so there's no prompt telling the user to correct it.

What changed

One new branch in javascript_web's detect(), reached only after the existing hasLockfile && (indexHtml || bundler) check has already declined. Nothing that matches today stops matching — this can only add matches.

With no lockfile, claim the project when both hold:

1. index.html is in the project root.
2. No server framework in dependencies (express, fastify, koa, @nestjs/core, hapi, restify, h3).

dependencies and not devDependencies, because a static site may well keep a server around to preview itself locally, and that shouldn't read as a backend.

Why root-only

Reusing the existing hasIndexHtml helper here is wrong. It globs **/index.html six levels deep, which is fine when a lockfile is corroborating it and much too loose when it's deciding alone:

Project, no lockfile	**/index.html	root-only
Node lib with docs/index.html	javascript_web ✗	javascript_node ✓
hono server + public/index.html	javascript_web ✗	javascript_node ✓
Portfolio with root index.html	javascript_web ✓	javascript_web ✓

Root-only carries most of the weight, which is the point: the fix doesn't depend on the server list being complete. hono isn't on that list and is handled correctly anyway, because its index.html is under public/. The list is a second guard for a server with a root index.html, so an omission from it is a small miss rather than a misroute.

What it doesn't cover

A site whose index.html lives under public/ or dist/ is still routed to javascript_node. Without a lockfile there's nothing separating that shape from a server's asset directory, and the wrong guess there is the same wrong guess this PR is fixing. So it's left alone deliberately rather than covered by a heuristic I can't defend. Pinned as a test so the limit is visible rather than surprising.

Also unchanged: a site with no package.json at all stays unclaimed. Routing those users to the JS snippet from the docs, as PostHog/posthog.com#18390 does, is a better answer than the wizard adopting static sites. Also pinned, with a pointer to that PR.

Tests

Nine in framework.test.ts, seven of them negatives: the docs/ and public/ cases above, express in dependencies against devDependencies, a Node project with no frontend signal, and the existing lockfile path unchanged.

pnpm build   ✅
pnpm test    ✅ 1565 passing
pnpm lint    ✅ no new errors

Refs #870, PostHog/posthog.com#18390