orchestrator: hardcoded customer template IDs bypass configurable ready-wait (HACK in GetDefaultReadyCommand)

Problem

GetDefaultReadyCommand in packages/orchestrator/pkg/template/build/phases/finalize/ready.go:81 hardcodes three specific customer template IDs to use a 120-second ready wait instead of the default 20 seconds:

func GetDefaultReadyCommand(templateID string) string {
    // HACK: This is a temporary fix for a customer that needs a bigger time to start the command.
    // TODO: Remove this after we can add customizable wait time for building templates.
    if templateID == "zegbt9dl3l2ixqem82mm" || templateID == "ot5bidkk3j2so2j02uuz" || templateID == "0zeou1s7agaytqitvmzc" {
        return fmt.Sprintf("sleep %d", int((120 * time.Second).Seconds()))
    }
    return fmt.Sprintf("sleep %d", int(defaultReadyWait.Seconds()))
}

Problems with this approach:

1. Silent breakage on rebuild — if any of these templates is rebuilt, the new build gets a different template ID and silently reverts to the 20-second default, breaking the customer's workflow without any error.
2. Not discoverable — other teams do not know this accommodation exists; similar customers cannot request it.
3. Undocumented constraint — there is no tracking of why each ID needs longer wait, making it hard to clean up.
4. Source-code coupling — a customer configuration is embedded in orchestrator binary; changing it requires a deploy.

Expected behavior

The ready wait duration should be configurable per template or per user via the template build API (e.g., a startTimeout field in the e2b.toml / Dockerfile label / API request), with the orchestrator reading it at build time rather than comparing against a hardcoded ID list.

Suggested fix

• Add an optional startTimeout (or similar) parameter to the template build request
• Pass it through to GetDefaultReadyCommand as a duration argument
• Remove the hardcoded ID checks once the affected customers migrate

The existing TODO comment already acknowledges this: "TODO: Make this user configurable, with health check too"

Start in packages/orchestrator/pkg/template/build/phases/finalize/ready.go at GetDefaultReadyCommand, then trace the template build request and the e2b.toml, Dockerfile label, or API request paths mentioned in the issue. Determine where a per-template or per-user startTimeout can be carried into the build. Done means the ready wait is configurable and the hardcoded template ID checks can be removed without changing existing behavior unexpectedly.