`handleApplication` 30s timeout aborts a legitimate `next build` (webpack) before it completes

## Summary

The on-startup production build must complete within Harper's **30 s `handleApplication` timeout**. A real cold `next build` (Next.js 16, webpack) does not finish in 30 s, so Harper aborts the component load before the build produces a `.next` — the app never serves.

This surfaces once you set `bundler: webpack` to sidestep the Turbopack crash (filed separately): with webpack there's no crash, just a timeout.

## Environment

- Harper (harper-pro) **5.1.23**, multi-node replicated cluster
- `@harperfast/nextjs` **2.2.3**
- `next` **16.2.11**, React 19 (App Router)
- Component config: `'@harperfast/nextjs': { package: '@harperfast/nextjs', bundler: webpack }`

## What happens

```
Error: Could not load component '@harperfast/nextjs' for application '' due to:
handleApplication timed out after 30000ms for @harperfast/nextjs on behalf of
```

No build error and no crash — the webpack build is still running when Harper's 30 s component-load deadline fires and tears it down. `GET /` returns 500 for the life of the component.

## Root cause

`handleApplication` runs the full `next build` inline (`build()` → `withBuildLock` → `runNextBuild`) and must return within the fixed 30 s component-load budget. Even a trivial app's cold Next 16 build exceeds that on the cluster, so the build is aborted every time. Because the abort happens mid-build, no `.next/BUILD_ID` is ever produced and subsequent restarts repeat the timeout.

## Reproduce

1. Minimal Next.js 16 app + `@harperfast/nextjs` with `bundler: webpack`.
2. Deploy to a cluster; `GET /` → 500 "handleApplication timed out after 30000ms".

## Impact

Even with the Turbopack crash worked around, the server-side-build model can't complete within the component-load window. Combined with the Turbopack issue, **neither bundler** can do an on-startup build on a real cluster today.

## Possible directions

- Do the build off the `handleApplication` critical path (e.g. build asynchronously and serve once `.next` is ready / return fast and mark the component "building"), rather than blocking the component load on a full `next build`.
- Make the build timeout configurable / much larger for this plugin, and/or persist a completed build so restarts don't rebuild from scratch.
- A dedicated build step / `buildOnly` at deploy time, then serve `prebuilt`.

## Workaround

`prebuilt: true` — build `.next` ahead of time and ship it; the plugin skips building entirely, so there's no build to time out. Verified working on 5.1.23.

## Related

- Turbopack "Worker creator already registered" crash (filed separately) — the reason one reaches for `bundler: webpack` in the first place.
- #52 build race, #37 build-vs-RocksDB lock.

Start by tracing handleApplication through build(), withBuildLock, and runNextBuild, then compare the prebuilt path with a cold webpack build. Done means a real cold build is not aborted by the 30-second component-load deadline and the app can serve GET / successfully.

Written by the indexing model from the issue text.