CacheComponents: RSC And Form Requests To Literal Dynamic Route URL Fail With E592

In app-page-runtime.ts, the hasPostponedState flag is only set from platform metadata at the start of the request. When postponed state is later loaded from the incremental cache during next start, the flag remains false, so fallbackRouteParams are still created for the literal [slug] placeholder. app-render.tsx then rejects the simultaneous presence of postponed and fallbackRouteParams for non-fetch-action requests with E592.

1. Clone https://github.com/uaoa/next-postponed-placeholder-repro and run npm install && npm run build && npm run start.\n2. Execute the four curl commands from the issue: RSC request, form POST, HTML control, and RSC control.\n3. Observe that RSC and POST return HTTP 500 while HTML and control RSC return 200.

This change assumes that when postponed state exists, fallbackRouteParams are never required. If a scenario exists where both are legitimately needed (e.g., certain fetch-action flows), this could regress rendering. Rollback by reverting the diff and instead extending app-render.tsx to allow the combination for RSC and form requests. Thorough testing with cacheComponents, fetch actions, and dynamic routes is required.