Atomic app builds on a dedicated esbuild service

Apps used to build on our API servers. An agent edit could trigger duplicate builds, concurrent builds were silently dropped, publishing cleared the running app until the next good build, and a crashed build could leave an app stuck on "building." We rebuilt the pipeline in two steps.

Queued, atomic builds (June 3)

• Builds are queue jobs, one active build per app. Triggers that arrive mid-build collapse into a single rerun with the latest files instead of being dropped.
• Build output is written to a fresh location and the app switches to it only when the build succeeds, so a failed build leaves the previous version serving.
• The app pane follows build status (queued, building, ready, error) and swaps in the new version as soon as it's ready. Failed builds keep the compiler output for you and the agent.

A dedicated builder (June 24)

• Builds run on their own autoscaling service, so bursts never compete with API traffic. The builder holds no credentials or database access and moves files through short-lived signed links.
• esbuild replaced Vite for bundling, and type checking reuses a warm TypeScript program, so library types are parsed once rather than on every build.
• Icon imports are rewritten per icon, cutting the icon library from about 4,500 modules to a few dozen.