Remixed project deployment stalls during dependency installation

Context

The Remix feature duplicates a project's files and environment variables, then triggers a fresh dependency installation based on the copied package.json. For projects with large or deeply nested dependency trees, this rebuild phase can exceed the platform's build-time or resource limits, causing the new instance to remain in a pending or failed state.

Uncertainty

It is unclear whether the platform applies the same build quotas to remixed projects as it does to initial project creation, or whether the remix operation inherits any resource profile from the source project. The documentation notes that heavy dependency trees "can lead to increased build times or deployment failures if the environment limits are reached," but does not specify which limits apply or how they are enforced during a remix.

Questions

1. Which specific build-time or resource quotas govern the dependency installation step when a project is remixed?
2. Does the remix process respect any custom build configuration (e.g., glitch.json install scripts) from the source project, or does it always run a clean npm install?
3. Are there documented workarounds—such as pre-bundling dependencies or splitting the project—to reliably remix large dependency trees without hitting environment limits?