test: cover ISR index cache key collision

[vercel-gh-bot-2]

What

Adds a production App Router regression fixture for the ISR cache-key collision between / and /index.

The fixture has:

• an ISR home page with revalidate = 1
• a root [slug] route with dynamicParams = true
• notFound() for the dynamic route

The test waits for a fresh home generation to become stale, requests /index, waits for its not-found result, and asserts that / still returns the cached home page with status 200.

Test precedent

This uses the native nextTestSetup({ files: __dirname }) production fixture pattern and retry() synchronization used by nearby App Router ISR coverage such as test/production/app-dir/ssg-single-pass/ssg-single-pass.test.ts. It uses no fixed sleeps.

Verification evidence

Stored verification vercel#57 against reproduction vercel#59 (642d9480045b080a6bb855121e16ca8d05d2874f) classified the issue as still_reproduces. node verify.mjs observed initial_home=200, index=200, and final_home=404 on both the reported 16.2.1-canary.18 and then-current 16.3.0-canary.86.

The new test was run on untouched canary parent 80fd3fed693b7aea14b7aed6eab5960ba5d94985 (16.3.0-canary.92) in both production bundler modes:

pnpm test-start-turbo test/production/app-dir/isr-index-cache-key/isr-index-cache-key.test.ts
pnpm test-start-webpack test/production/app-dir/isr-index-cache-key/isr-index-cache-key.test.ts

Both builds and servers completed normally, then the regression assertion failed for the expected reason:

Expected: 200
Received: 404
expect(finalHome.status).toBe(200)

Formatting, ESLint, and git diff --check also completed successfully.

Expected CI state

This is intentionally test-only. The focused production test is expected to fail with both Turbopack and webpack until the framework cache-key collision is fixed.