next.js

554a1e3c - Fix Navigation Inspector Continue Rendering with loading.tsx (#94355)

Fix Navigation Inspector Continue Rendering with loading.tsx (#94355) ## Summary - Add regression coverage for Navigation Inspector `Continue Rendering` with a route-level `loading.tsx` - Fix Instant Navigation lock timing by snapshotting the active lock when a dynamic request starts - Prevent inspector re-arm from trapping in-flight dynamic responses behind the next capture lock ## Why The Navigation Inspector recently changed `Continue Rendering` to re-arm capture after releasing the current lock. That surfaced a race in the lower-level Instant Navigation lock handling. The flow was: 1. `Continue Rendering` deletes the `next-instant-navigation-testing` cookie. 2. Deleting the cookie releases the current navigation lock and triggers a soft refresh. 3. The inspector quickly writes a new pending cookie to re-arm capture. 4. A route-level `loading.tsx` navigation may still have dynamic data applying from the unlock-triggered refresh. 5. Before this change, `fetchMissingDynamicData` waited on whichever lock was active when the response was applied. That meant the refresh response could accidentally see the newly re-armed lock and suspend forever. This surfaced with `loading.tsx` more reliably than inline Suspense because the route-level loading boundary commits the segment loading shell, then final content depends on the unlock refresh path. Inline Suspense generally keeps the deferred dynamic work associated with the original captured navigation, so it waits on the original lock and resumes when that lock is released. ## Fix Dynamic requests now capture the current navigation lock when the request starts, then wait only on that specific lock when applying the response. This preserves the intended behavior: - Requests started during a capture still wait for that capture to release. - Requests started after unlock are not blocked by a later re-arm. - The inspector can continue re-arming capture without racing in-flight refresh responses. Conceptually, a dynamic request should wait on the lock that existed when that request started, not whatever lock happens to exist later when its response is applied.